So I want to create a C# application that can be transmitted to users which can then run an "exe" file copying the data files. Therefore, the application should contain at least to things:
The "exe" file
The files containing the data
The data in the application will be in most cases a directory with files and subfolders. My concern is how to store this data. I was thinking about storing the data in ".bin" files while being able to read the data with the exe file and place the files/folders in the correct structure, but I don't know exactly how would I do that with files and folders. Does anyone have any suggestions ? Is there a better way? Do you have any recommended reads ?
Thanks!
When you compile in either debug or release mode, there will be an .exe file in the bin/debug or bin/release folder for your project together with all the project files. You can move that to whatever machine with the .NET framework installed and run the .exe.
If you want to make an actualy executable, that's more difficult to do. Check out this post for more inspiration on that.
If your build is meant for distribution, better compile it on Release mode.
You will find the assemblies on your project_folder/bin/Release.
You may want to copy all contents in the release folder by compressing it, or better yet, using an installer compilation tool, like InnoSetup - http://www.jrsoftware.org/isinfo.php/, that is free and will do your application installer just fine.
Related
I have designed and created two seperate windows application ( say winapp1 and winapp2). Winapp1 creates a file(say file.txt) in the disk containing some text. And I need to merge this file.txt with precompiled version of winapp2 ie winapp2.exe so that the winapp2 can display it.
Winapp1 creates a file with different contents each execution time. And for each file there will be a copy of winapp2 that needs to be merged.
Is there a way to this? If there is, help me.
And my English is not so good. Thanks for reading this.
The easiest solution, (assuming that releasing the source code for winapp2 to the system that runs winapp1 doesn't present problems) is to have the entire source for the winapp2 project accessible to winapp1. The source should include a blank copy of the file as an embedded resource. Winapp1 can then modify the source file and use MSBuild to build a fresh copy of Winapp2.
To modify the text file, you should be able to just use the normal file manipulation .NET methods and to call MSBuild, you may be able to do it via a .NET class, but you can certainly just call the msbuild executable from the relevant .NET framework folder in %windir%\Microsoft.NET\Framework\ and pass in the full path of the project file.
Everything in Visual Studio seems to lead one to putting data files with the application.The app.config goes there, when I create an .XML data file, there is a Copy to Output property that will automatically copy that file to the exe folder. Howerver, it seems that under Vista and Win7 UAC doesn't want the application to be able to write data to any file in the application directory. So I'm changing my evil ways so that I use the LocalApplicationData folder for files I want to read and write. (I just read the app.config so I'm leaving it alone)
I'm using a VS2010 Visual Studio Installer project to create the installer for this app and I can't seem to find a way to target the folder for my .xml file to the LocalApplicationData folder. I can click on the file and see a Folder property but the dialog only has options for Application Folder, User's Desktop and User's Program Menu. Is there some way to do this in the installer or do I have to write code that checks for the file and copies it over from the .exe folder when it doesn't exist? I figure I'm late to this particular party and there must be a canonical way of handling this.
Also, I'm wondering about debugging, is there something similar to the copy if newer functionality in the build process that will now copy this .xml file automatically over to the LocalApplicationData folder whenever I update it?
The Setup project doesn't expose LocalApplicationData in the Special Folders list. You can use it anyway by doing this:
Add a Custom Folder and set the DefaultLocation property to [LocalAppDataFolder]
Having created a WPF/C# demo application (in Visual C# Studio Express), what are the minimum files I would need to zip up, to give the source to someone? (Not deploy an executable, but enough actual source code to recreate the project).
Obviously I need the *.xaml *.cs *.sln *.csproj files.
Do I need *.suo *.csproj.user, or are those specific to my editor?
Do I need any or all of the files in the Properties directory? Some of those files say auto-generated, which would seem to imply they're not needed.
I'd share the Properties files as well, it generally being a good idea to share and version all files that are needed to compile the project regardless of the IDE. Since it's an IDE tool that generates those files, I'd consider it bad form to leave them out, in case you want to set up a Continuous Integration server or something of that sort.
The *.suo files are Solution User Options, which kind of implies that they're per-user, not per-project. Same goes for the *.user files.
the simplest thing is to delete any obj/bin directories (if they exist), and just zip up everything else.
the .user and .suo are things that will get recreated, but there's no harm in sending them (unless they are really big!)
That being said, it really depends on the details of your project, and how you have it organized.
Just wondering what the standard practice is. Removing these folders before uploading makes the downloaded files easier to sort through and reduces the file count and size of the project (faster download). However, the downloader has to rebuild it to run it in his IDE of choice (in this case, VC#).
I will most likely have a separate download for the compiled binary so I imagine that removing the bin and obj folders would be desirable? Also, removing these folders remove all exe's and compiled files from the source code so they can be shared by services such as Gmail (Gmail does not allow emailing executables) without hassle.
yes, the obj and bin folders are generated by build process and are not needed by other developers to open the solution and rebuild the projects.
in general you should strip out also .suo files and other user specific files Visual Studio could create locally.
Yes, you should remove the binaries. As you said, you can offer separate binaries to download. If you have binaries in your version control repository, it also adds a bunch of unneeded file changes to your source control, making it harder sometimes to see what the real changes are.
I've never burnt a visual studio program to a CD before. I've made a setup project with all my program files, and it works fine. Do I simply need to burn the following installer files onto the CD and give it to someone?
The installer is a folder containing:
-DotNetFX35 (Folder): Contains .net requirements for my program.
-WIndowsInstaller3_1 (Folder): WindowsInstaller-KB893803-v2-x86.exe
-setup.exe
-My Installer.msi
Sorry for the seemingly easy question. I'm double checking as I have one CD and an impatient employer.
Thanks!
You will need to add an autorun.inf if you want autorun to work. Put the contents of the install folder at the root of the disk, create a simple text file called "autorun.inf" at the root of the disk and add the following contents:
[autorun]
open=setup.exe
This will instruct the operating system to run setup.exe when the disk has inserted (and consented to it).
There are other tricks you can do with autorun.inf too. As many have mentioned in the comments, the best way to test this is by creating an ISO and testing it, or buying a stack of blank disks. They are pretty cheap these days.
If you don't care about auto run, then you can put anything on the disk itself, it's just content, the user would just need to go into the contents himself and click setup.