Having a bit of an issue here. I'm creating an application in Visual Studio 2010 in C# (Windows Forms).
The UI is going to be done in a WebBrowser (so I can use jQuery goodness and for ease of development).
For this I want to create a folder called HTML which will store all my HTML files and my javascript files.
My colleague tells me to create the folder separately and copy and paste into the compiled application directory referencing the files using: System.AppDomain.CurrentDomain.BaseDirectory.ToString() + "HTML\\FirstPage.htm" etc...
This seems strange to me. His argument is sound - if you need to edit/change anything then you don't need to open your VM (we're on Macs) open Visual Studio, edit, recompile, redistribute etc you just open the HTML files in the application directory. (my argument to this was that its just not that much extra work!)
I can see problems coming when different versions of the HTML files start getting mixed up and such, and to me it feels more "right" to compile the files directly as resources - OR... at least have them as files within the project explorer in Visual Studio.
So my question is: What would be the best way to do this? Would it be best to compile the HTML files as resources (and how would I do that? I'm very new to all this)? Or would it be better to do it the way my colleague said? If so is there a way to get Visual Studio to automatically copy the latest version of the files into the application directory at build time?
Thanks a lot.
No need for resources, they are far less manageable.
Easiest solution will be to add the folder with all the files to the project, and then, in their properties set:
Build Action = Content
Copy to Output Directory = Copy if newer
That's it!
Now whenever you compile your project, all these files would be updated with the latest version.
Related
I'm new to c#, and i'm stunned by the amount of files that are generated by my release output.
I wrote a REALLY simple program that i want to distribute, no external assets or anything special.
but still, there are 10-15 files generated (.dlls, .pdbs, .configs, etc. etc.)
I did a little research yesterday and i got the impression that it is simply not possible to clean up this mess without a REALLY big hassle?
i tried Fody (didn't work at all) and Tidybin (or something like that?) (created a lib folder and put everything there, which was nice, but the program stopped working and threw errors about the missing files)
I'm looking for a way to generate a clean release version.
ideally with JUST my exe, with all the dlls and other stuff embedded, but everything i read about that was just way above my head and overly complicated (why isn't this super easy to do???)
if that's not possible, i'd be happy with moving everything except the .exe in a lib folder. but that didn't seem to work. how do i update the path inside my application, so that those files can still be found? like i said, that plugin seemed to do half the job, while leaving all links like they were.
(side note: why is there not ANY KIND of ducomentation for all of these plugins? i really don't have the SLIGHTEST idea what to do)
thanks
If you have a simple application, there shouldn't really be that much in the folder.
Actually, there should be:
1 exe, 1 pdb (only for debug build), 1 exe.config file for the application
1 exe, 1 pdb (only for debug build), 1 exe.config file for the Visual Studio Host Process
If there is the System.Net.Http library referenced, this could create a folder with many localizations. If you don't use it: Remove the reference.
Please note that you do not need to deploy all these files! If the application only references framework DLLs, all you need is the .exe and .exe.config file.
DLLs will not be embedded, but if they are framework libraries, they should not be added to the output folder unless you set the "Copy Local" property of the reference. And you don't need to deploy them along with your application, as obviously they are installed along with the .NET framework on the target system anyway.
If you reference any DLLs that do not belong to the .NET Framework, you normally deploy them along with your application. It's easiest to put them in the folder along with your application, but you can also put them in the global assembly cache on the target system.
There are solutions that package the executable, third party DLLs and stuff into an EXE wrapper that is unpacked every time you start the application, but I advise against this. The user won't expect this to happen, virus scanners may block this and builtin mechanisms like .NET settings may not work properly for those solutions.
The easiest way to distribute your code is using InstallShield Visual Studio edition. (That is available with your Visual Studio license)
Download and register, then add a new distribution project to your solution.
InstallShield Limited Edition for Visual Studio
A wizard will help you by selecting the main distribution files. And it is a useful tool distributing new releases of your application.
As a second option I use is ClickOnce (Microsoft), but for specific internal applications.
ClickOnce Deployement
I would like to make a backup copy of my Visual Studio 2013 MVC application which is only the source code. Such that I could open the solution on a new machine and have it compile after NuGet has downloaded the necessary packages and so on.
I realise that if the project was in TFS or similair I could go to the new machine and download it like that, however I am looking for a file copy solution.
Now while I could ZIP up the entire folder including binaries that seems like a sledge hammer approach. Having looked around there does not appear to be an easy way to do this. Has anyone got a solution or a utility I may have missed?
Use a version control system such as TFS, Subversion, PlasticSCM, git whatever. Seriously. Distributed VCSs like git or Mercurial will let you transport the whole repository easily.
If you insist on a pack&go approach, the ZIP tool of your choice will, most likely, support include / exclude rules based on file name patterns. For example, in Total Commander it's easy to exclude bin and obj folders.
I am not sure how this feature is called in English but there is something like Clean solution in Visual Studio. This will delete all the binaries and stuff that can be generated. I am not sure it will also delete NuGet downloads but you may give it a try. Afterwards, you can simply copy the project or solution folder.
I made a library which uses .xml files for configuration. But in the core project, which use this library, ressources are not copied. I added a reference to my library.dll but of course there is nothing that says i need to include /configuration folder of the lib project.
How can i achieve that ? (manual copy is excluded)
ps: im working in c# with visual studio 2012 ultimate. both project are c#. One generate a library (dll etc..), other is executable project.
Thanks in advance :)
Right click and select Add > Existing item to include the resources into your project.
After including them, select them under the Solution Explorer, right click and select properties. Look for Copy to Output Directory, and set it to Always. That should copy the files along with your project.
Another option if needed, may be to set Build Action to Embedded Resource, but that might make it a little more complicated (but not impossible) to access the files from your application.
Update: Accessing a file that is embedded is a little more messy, but this other SO question might help you out.
So I made a C# program, and its great and all (its a Windows Form Application). The issue with it, is I don't know how to use it outside of the debug mode form. How do I publish it? My target goal is to create a two folders, put a shortcut to the application in one, along with the other folder which will contain the application and all outside programs (some of the buttons link to batch files). Then I'd want to be able to put it in a RAR compressed file, and upload it online for others to download it.
How do I publish it so that happens? How do I take it out of debug mode?
Go into your project folder, then navigate to /bin/Release. If there's an EXE file with the title of your project in there, copy it somewhere (along with any DLLs that you may have linked) and there's your program. If it's not there, first try Build -> Compile Solution in Visual Studio. If it's still not there, navigate instead to /bin/Debug and do the same thing. Then, copy all your batch files into another folder, put them into the same folder, and RAR it.
P.S. Try not to use RAR, few people can extract them. Use ZIP or SEA (self-extracting archive) if at all possible.
First off, you need to build your application in Release mode, in Visual Studio simply change the drop down near the top of the window to "Release." This will create a bin/Release directory where your sources are located. The folder will contain an EXE for your application and DLLs you need to include. It could (and probably will) include some debugging *.PDB files that you do not want to include -- as those include debugging information.
Copy the contents of that directory somewhere and RAR it up.
Building in x86 Mode
(You should only do this if you have a specific reason to)
If your application uses 3rd party DLLs that are not 64-bit compatible, you may need to do a release build in x86 mode. To do that, click the "Any CPU" drop down and click "New Configuration" (or something like that) and follow the steps to add x86. Then build with the x86 -- Release setting. That will output x86 binaries to a bin/x86/Release folder where your sources are located.
The Preferred Soltuion
Most users are going to prefer some form of automatic installer instead of a simple RAR or ZIP. Visual Studio (Standard/Pro) can create self installing MSIs that do all the work for you. A basic overview is here. You can add shortcuts/etc using the wizards Visual Studio provides.
If you need an even more robust installer you could check out solutions such as InnoSetup or NSIS
To build your application in Release mode instead of Debug, go to the Build menu and select Configuration Manager.
Change the Active soluction configuration to Release. Now, when you build your solution, it will put the executable in the /bin/Release folder.
If you need to automatically perform certain actions once the solution is built, like packaging into a RAR or ZIP archive and copying the distributable to another folder, then check out post-build actions.
After Visual Studio 2010 , Microsoft remove Make setup utility facility from the visual studio and,we have to downlorad that plugin seperatly from
Get InstallShield Limited Edition for Visual Studio
You Have to fill the application
After intalation, goto
Visual Studio-->New Project-->Other Project type-->Setup and Development
You will see follwing screen
Now you can goto InstallShield setup utility and change the things as you requirement.
add all file in debug folder of your project in follwing interface and build solution,
Final setup will locate in your setup folder-->Express\CD_ROM\DiskImages\DISK1**
hope this will help you
I am building an application which is based on a sample application,
written in C# on .NET 2, and is built on VS2008. This application is mostly a wrapper for a COM application.
However I compile it in .NET 3.5.
The sample application came with the following files in it's bin\debug:
appName.vshost.exe
appName.vshost.exe.manifest
I noticed that I can delete the files and VS re-builds vshost.exe, and the vshost.manifest file appears with modification date the same as the deleted file as if VS has copied in from somewhere.
My question is, should I put this files in my SVN code repository?
Those two files you list implement the Visual Studio "hosting process". It is a hosted version of the CLR, designed to improve the debugging experience. It takes care of some security issues, the most visible side-effect is that it redirects output written with Console.WriteLine() in a GUI app to the Output window.
These files are not part of your project and do not get deleted when you use Build + Clean. In fact, you cannot delete the .exe file, it is always running while you've got the project opened in Visual Studio. You can disable the hosting process feature with Project + Properties, Debug, scroll down, "Enable the Visual Studio Hosting process" tick. There's no compelling reason to do so.
There's no need to check these in, Visual Studio re-generates them when you check-in a project and load it in VS. In general, you never need to check anything in from the bin subdirectory, its content is always re-created by building your project.
Everything in the debug (or release) folder is generated. Everything that's generated shouldn't be checked in.
When in doubt, just make a fresh checkout to some other folder (or even machine), and try to build from that. If something is missing, this will find it.
I do not think you should. They are for VS use only.
Here are the files I ignore when creating C# projects. You really only want to store the source code in the repository and not the outputs. Similarly you probably do not want to store the user based information that goes along with VS solutions.
*.csproj.user
*.suo
bin (folder)
obj (folder)