CODEWITHSUNDEEP
c#visual-studio
devman
devman

Reputation: 701

How to clean up my VS2015 release files

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

Upvotes: 0

Views: 89

Answers (2)

McNets
McNets

Reputation: 10817

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

Upvotes: 0

Thorsten Dittmar
Thorsten Dittmar

Reputation: 56727

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.

Upvotes: 1

Related Questions