views:

703

answers:

4

Hi there!

I have just finished a WinForms app, and its working great! Now, time to deploy. Issue is, that I dont want to create a setup file, but rather a single executable, for example 'myApp.exe'. The reason for doing this, is because it will be redistributed on CD media, and it is supposed to auto-run as a stand-alone app when the CD inserted into a user's PC.

Any thoughts here?

Secondly, how can I create a reference to '.txt' files contained on the CD from within the app? I want to provide links to the files, but Im unsure as to how to do the path reference.

TIA...Im really puzzled here!

+1  A: 

You can use embedded resources within the exe instead of seperate files: http://jopinblog.wordpress.com/2007/11/12/embedded-resource-queries-or-how-to-manage-sql-code-in-your-net-projects/

JohnOpincar
Ok, thats cool. But would this work in this instance...Im using MS Office PIA, so Im actually using mail merge to write to some template fields in a MS Word '.dot' template document. Should I still embed this?
Shalan
Oh, sorry...were u referring to the DLLs that get built when compiled?
Shalan
No, you can embed any type of file you want. Not sure about the MS Office part though.
JohnOpincar
+2  A: 

When you reference the '.txt' files in your code, just use the relative path from where the app is being executed from. For example if your .txt files are in the same directory as the executable, refer to them without any path ("filename.txt") or you could use (".\filename.txt").

As far as not installing your app, just make sure you are not using any 3rd party libraries that would need to be installed on the clients and just burn the contents of your apps /bin/ directory and use an autorun.ini file to launch your exe.

devSolo
hey devSolo! thanx for that! I usually keep all my files in a folder called "assets", so I can reference the txt file as ".\assets\file.txt", right?I am using 3rd-party dlls, but under the References folder in the solution xplorer Ive set their "copy Local" propoerty to true. One thing though, in the past when I built a solution, 2 folders used to appear under bin - "debug" and "release", the latter of which is not there anymore. I know this is the one to use, but cant seem to see it. Sorry, its been a while since I built a Winforms app! thanx!
Shalan
yep, the ".\assets\file.txt" will reference the assets folder in the same path as your executable is executing from. And as long as your dlls don't need registration, and simply need to be referenced in your application, then they'll work fine. I believe thats called xcopy deployment(for lack of a better term). And as far as your missing release binaries, you can switch between debug and release by clicking on (In visual studio) Build->Configuration Manager... and then you can change the Active solution configuration. The "Standard" Toolbar also has a drop down list box with them.
devSolo
Thanx for the assist devSolo! Will definitely check that out
Shalan
This uses the current directory of the application, which can change over the life of the application. It can also be set to a different location by the user before the application's even started. It isn't correct. Please see my answer.
Greg D
A: 

Hi. For those interested, what also worked for me, where I needed a reference path from the application executable, was to use "Environment.GetCurrentDirectory"

So for example, I provided the path to my MS Word .dot Template as:

Object templatePath = Environment.GetCurrentDirectory + "\\Assets\\MyDocument.dot";
Shalan
Please don't do this, it's incorrect in the general case.
Greg D
+1  A: 

@Shalan, re: your answer:

Be careful! You'll upset your users and maintenance programmers!

I've seen and fixed this error at least a couple dozen times.

Are you sure you know what the current directory is? The OpenFileDialog and SaveFileDialog can change it, for example, and then you'd fail to find your .dot file.

What if the user starts the app with a different working directory? Then you'd also fail. Remember that you can't control your working directory-- your app will fail if the user changes it from the default.

If you must find the application executable's path, consider using Application.StartupPath along with System.IO.Path. E.g:

string dotSubPath = System.IO.Path.Combine("Assets", "MyDocument.dot");
string templatePath = System.IO.Path.Combine(Application.StartupPath, dotSubPath);

This will always get the path based on the application's startup directory, not just the working directory.

Greg D
WOAH! thanks for the heads-up, Greg! As I mentioned at the top, the release files will be copied onto CD and the EXE will run directly from the root of that CD. But becuase the drive letter of users' optical drives will be unknown, I chose to go with the aforementioned route instead. No dialogs are being used within the app, and I must admit that it appears to work. Please explain to me what is meant by "working directory" is this instance. Thank u!
Shalan
...IN this instance....
Shalan
It will appear to work b/c the default directory is the executable directory. You can't guarantee that users will always run it precisely with the default config, though. There are many different ways that the current working directory may be changed. There's no additional cost to doing it the right way, either. E.g., can you be sure that no future version of this program, ever, will use a dialog? Of course not.
Greg D
Good point and duly noted. Thanks Greg, I will certainly take your advice on that!
Shalan