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
Related
I'm coding a simple application that I need to be portable (the user can just run it by clicking on the .exe without having to run a installer).
All the other questions on this subject that I found on StackOverflow wants to make .NET Framework "bundable" with the software, but I don't need that.
A workaround that I found is going to /bin/Debug on the project folder and use the .exe there, but that seems "wrong". Is there another way to make a software written in C# portable?
Thanks!
EDIT: Okay, I'm really dumb and I asked all the wrong questions. However, your answers pointed me to the right direction. I wanted to know how to generate the .exe to send to my friends. What I had to do is change this to "Release" and press F6. I added this so if someone with the same "doubts" that I had can find the answer easly. Thanks!
Going to bin/Debug and using the DLL there is wrong.
Instead, build and copy the one from bin/Release.
If there's anything else inside the folder, though (except *.pdb), then beware. Your application might need those additional files. For example, the app.config.
All .NET applications are "portable" as long as the machine you are running it on has the version of .NET you are targeting (or a compatible version). The key here is to make sure that your application does not depend on things that an installer would take care of for you to make your application work. Examples include: registered DLLs (like Interop assemblies), registry keys, or components that must be found in certain locations (such as having something stored in user's AppData folder).
As long as the machine you want to run it on has .NET framework, you can make any .NET application portable. If the app you're making has no dependencies other than .NET then it's fully portable already. Even if it does have dependencies just include those with the executable.
To expand on Zerkms's comment:
Every software is portable by default. Installers are a way of telling to program to search for resources in a certain place, meaning that if the place isn't there, eg: C:\Windows then the program won't be able to run.
So as long as you have the application have the resources already within the exe or a root folder search (so where the program is, rather then where it should be) then you'll be fine.
If you're using default controls, it should be fine as long as your software's running framework version is installed on the computer. If you're using 3rd party controls, you can emded the dll's into the .exe upon compiling. Do note that the more dll's you embed, the bigger the .exe file will be.
I have a large solution currently under VS2010, with lots of projects and dependencies. Some of them are installed to the GAC, some of them are just included from a "lib" folder. I need to build one of my projects (specifically a WinForms app) to able to run on any, non-development computers without any installation process (except for the .NET runtime of course), just as portable apps do.
For this to work, I need to have all of the referenced DLLs and their whole dependency tree in the output folder of my EXE. I can do it for exemple by marking the dependencies to "Copy local" in the properties window, but that works only for the direct references of the EXE project, so it's far not enough. Another way is to make a setup project, but my client and also I want to avoid that (in the final version I'm gonna use ClickOnce). Of course I can always do it purely by hand, gathering all the DLLs manually, but that's quite a nightmare.
Is there some tool, msbuild trick, command-line option, whatever hack to force Visual Studio to gather the whole dependency tree of my EXE during build, and copy them to the output folder? So that I could just ZIP everything together and send to my client.
I actually chose a somewhat "middle" solution, the following way.
I created a "dummy" setup project, not caring about setting anything but adding the project outputs (primary output, localized resources, contents, etc.). It was a 2 minute task this way.
I built the setup project, and got the MSI file as the output.
I've extracted the contents of the MSI file to a specific folder, called "MyAppPortable" for example. I found the solution here. The command-line command is
msiexec /a "absolute_path_to_my_MSI_output" /qb TARGETDIR="absolute_path_to_my_desired_output_folder"
I got the full application with all of its resolved dependencies (except for late-binding dependencies, but I took care of them manually, by adding them as references to my projects). I could ZIP the whole folder, put it on another computer, and voila, everything worked fine.
Basically, using Visual Studio, you can set all of your Solution's Projects to build into the same Output folder and use this folder as your Windows Form application folder (where the application EXE will reside).
By doing this, you will coordinate all of the possible assemblies references that your app is depend on.
In VS 2012, right-click on a Project => Properties => Select Build (left pane) => Set your Output path:
I would select a a solution-level folder as the Output path.
And if it's prohibited to perform such a modification at your workplace so I would suggest you to use dependency analysis tools like the following in order to interrogate and gather the appropriate assemblies that your app is depend on and will require at run-time:
Dependency Walker
NDepend
Red-Gate Reflector
Update:
Using the above mentioned tools will not yields assemblies references which are late-bounded (at run-time), for this case you may use: Fusion (the Assembly Binding Log Viewer)
Check out the Fody/Costura recommendation from this question:
Embedding DLLs in a compiled executable
It's great! I just tried it out for a similar need and in less then a few minutes I had a completely portable (except the .Net framework) exe that I could easily give to co-workers.
In VS, I've only tested code and debugged it, but never actually prepared anything for a finalized program or release. Some of the programs I've downloaded have had dlls that need to be in the folder they're in, and I've had programs that come as just one .exe. Is there a way to compile all the files into one application and not have external dlls? Is this bad programming practice for some reason? How do I compile my VS program into one executable file?
I know this is quite an obvious question, which is why I can't really find an answer, because it would be too obvious to write any kind of tutorial on it.
With a managed language like C# or VB.NET, ILMerge is a utility that you can use.
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output.
If the question is just around getting VisualStudio to build executable programs, it does it every time you run them within it. If you are using all of the default settings, open your project folder and look for a /bin directory. Underneath it, there is a /debug and a /release directory. If you build your program in debug mode, look in the /debug directory, if you build it in release mode, look in the release directory. VS will put everything that your program needs within that directory. You can copy all of those files to another machine that has the .Net runtime installed and it should run.
If the question is more about combining multiple dlls into a single exe, actually, there is a tutorial on it at CodePlex:
As you know, traditional linking of object code is no longer necessary
in .NET. A .NET program will usually consist of multiple parts. A
typical .NET application consists of an executable assembly, a few
assemblies in the program directory, and a few assemblies in the
global assembly cache. When the program is run, the runtime combines
all these parts to a program. Linking at compile time is no longer
necessary.
But sometimes, it is nevertheless useful to combine all parts a
program needs to execute into a single assembly. For example, you
might want to simplify the deployment of your application by combining
the program, all required libraries, and all resources, into a single
.exe file.
http://www.codeproject.com/KB/dotnet/mergingassemblies.aspx
Lastly, if the question is about building an installer for broad distribution, Jan Willem B has a sample for WIX: Using WIX to create an installer: quickstart tutorial
Yes, you can use ILMerge for embedding managed .Net DLLs! Example here.
We are using TFS and VS 2010.
I have been working on a project that is using TFS as source control.
I have quite a few dlls that I have downloaded (such as log4net) and referenced in my project.
When a new programmer connected to TFS and got my project out of source control, it failed to build as it said it was missing all these referenced dlls.
What did I do wrong here? How can I include those referenced DLLs in source control.
Do I need to add all these dlls to my project before referencing them? when I referenced them, I just browsed to where they were on my file system.
I've found the best practice for 3rd party DLLs is to create a "Library" folder in your sln/proj file structure and copy all the necessary DLLs into this local folder for reference. You'll also want to make sure these DLLs are checked into source control. This way, everyone who works on the project gets the exact same versions of all DLLs, and the reference paths are exactly the same.
Referencing 3rd party libs in a arbitrary download or install location will be problematic, because it will require all developers to maintain the same download structure for all DLLs. Also, if everyone references DLLs outside of the project structure, it's harder to guarantee that everyone's on the same version.
The other option would be to have everyone install the DLLs into the GAC, but that can be a real pain too, especially with version management and deployment.
I created a "ThirdPartyDLL" folder in my project folder in which I copied all the extra DLLs into it. I then went into source explorer and added those DLLs into the team foundation server so I could be sure I'm using the correct versions of the DLLS for specific versions of my application (and so everyone else is on the exact same page as I am).
View - other windows - Source coontrol explorer
Right click project folder - add items to folder
You won't be able to select a specific folder with DLLs in it, but instead you can select the individual DLL files within the folder. You will then see the "ThirdPartyDLL" folder appear in that window.
Once this is done, those dlls are in the team foundation source control. Whenever a dev checks in, they will get the most current version of the DLLs.
Don't forget to remove the old references in your app and change them to your thirdpartydll folder.
I used to copy the DLLs into the bin folder but the issue I ran into was when the DLLs got upgraded. Initially when my project was small it wasn't a big deal. Now that I have multiple DLLs and applications that I created it became very difficult to maintain consistent versions of DLLs outside my project. My best example is the licensing dll I purchased. When this got upgraded all applications and libraries needed to be on the same version. If I forgot one then I had weird issues or the application just stopped working. Now that I have everything in one folder, I make the change once and everything is upgraded.
Hope this helps.
Andy's suggestion is a good one and I've used that in the past. At my current job, we have a "reference" folder on a network share for all of us to build from. We have a very fast network here, though and all developers are in a single office. This solution won't work as well if you have a lot of remote developers or a slow network.
I've tried various methods for dealing with this and have settled on dropping required dll's in the bin folder and making sure they are included in the project for source control. I've heard people say this might not be a good idea but nobody has provided good reasoning for it and it's worked well for me.
My second choice would be to carve out some space on a network share and organize the various 3rd party dll's there. You can put your files in folders with verion numbers to keep things straight and everyone should have access to everything they need, so long as everyone uses the normal network paths as a reference.
Adding a seperate folder within the project is also workable but seems messy, since you end up with extra files that you don't want included in your release.
Is it possible to deploy a .NET 2.0 application as a portable executable?
So that my program can be ran in a Flash Disk without the .NET Framework 2.0 installed in the target machine. Or maybe is it possible to distribute my program with the required .NET DLLs, so that no framework installation is necessary?
I know that there are some alternative tools to turn my .NET exe into a single native executable like RemoteSoft Salamander, Xenocode Postbuild, and Thinstall, but unfortunately I can't afford one.
I also tried to embed the dependencies with Mono's mkbundle, but it messed my program up =\ (no XP visual style, broke some controls and its functionality)
Any kind of help would be appreciated :)
Thanks.
fyi: my IDE is Microsoft Visual C# 2008 Express Edition with .NET Framework 2.0 as the target framework.
Well, other than things like Salamander and Thinstall (now VMWare ThinApp) you would have to have .NET installed if you really want to run .NET.
It may be possible to run Mono without actually installing it (not statically linking your program, but including Mono on the flash drive). I suspect it would be tricky though, as you'd have to tell the runtime about things like the GAC location.
I can't see anything in the Mono FAQ about this, but you might want to ping a Mono mailing list - it sounds like a potentially interesting and useful thing to be able to do.
No; you need either the framework installed, or the tools like you have mentioned.
You could potentially look at mono's new static linker, but that is about it...
I have not tried this myself but here's the procedure:
Make a C# project.
In Solution Explorer, inside your project, there is a line "Reference". Click the plus near it. Now you can see all the dependencies of your project. Delete all references that aren't used (delete, and try to run/build. If it is possible to do it, that it is unused. If there is an error, return it by adding it (right mouse click, "Add Reference")).
For each reference, go to Properties, and in the property "Copy Local" choose "True". For each Image, Icon... make like to the referenced.
Rebuild you project. Now in your Build/Release folder (inside bin) you will see many dll files. Those files have the information of every resource.
Copy all the files in the folder (from step number 4) into a new folder.
Go to the folder: "\Microsoft.Net\Framework\" and copy the file "mscrolib.dll" to the new folder from step 5. If you don't find this file, you can always make a search in the Hard Drive which contains Windows folder.
Now your app is portable (with the whole folder content).
-- Source: http://www.codeproject.com/Tips/392308/Csharp-Portable-Exe-File
Well Thinstall is very expensive and it doesn't work in all situations. If you want to run your app without .Net installed you might run into trouble although there are tools that do that Xenocode has a tool that can do this for you and it's cheaper than thinstall.
But if you ask my opinion it's a bad idea to use them. Better convince your target market to install .Net 2 (Which is pretty much universal these days), and then pack all of your library files into one file using a cheaper Obfuscator like tool (There's a good one from Smartassembly.)
I've used Thinstall for a long time, and I've worked on this technology a lot, so I am not shooting off without experience.