Question How Do I Package and install a Released compiled version version of my .Net Framework?

complete

Active member
Joined
Oct 24, 2012
Messages
35
Programming Experience
3-5
How Do I Package and install a Released compiled version version of my .Net Framework?
Do I bundle the contents of the Release folder or just the EXE's and DLL's? Do I need to include the app.config and packages.config?
Do I need to create an installer somehow?
 
In general, everything in the Release folder gets deployed. That is on the assumption that your build scripts doesn't put extraneous stuff into the Release folder. Most pre dotcom bust devs were fastidious about ensuring just the bare minimum needed because back then, disk space was still at a premium, slower download speeds, and possibilty of packaging via CDs or floppies.

Depending on your (or your team's) philosophy, you might want to skip deploying any .PDB files. Do you need to debug on your end user's machine, or need to get detailed call stacks?

Depending on what you are releasing, you may not need to deploy associated .XMLDOC files. They have the helpful information from your embedded documentation for other devs, but if only end users will be targeted, do they need the API docs?

As for how to package all of that up, it depends on your deployment strategy and your target platform/environment.

Often if you are in corporate network and you are pushing to desktops and don't need to set any registry settings or create databases, simple XCOPY deployments will work, and you can just have loose files. Or there is ClickOnce which again in general is just loose files and some versioning metadata. Or if you have a web app that just needs a one time configuration of IIS/NGinx/Apache, you can get away with loose files.

If you need some special configurations in the target machine (registry values, databases, folder structures, permissions, etc.), then look into building a .MSI. Or a MSDeploy package for a web app.

If you need to deploy as a new Windows Store App, you are forced to build using MS's app packaging (unless you have very tech savvy users who are not afraid of the command line).
 
In general, everything in the Release folder gets deployed. That is on the assumption that your build scripts doesn't put extraneous stuff into the Release folder. Most pre dotcom bust devs were fastidious about ensuring just the bare minimum needed because back then, disk space was still at a premium, slower download speeds, and possibilty of packaging via CDs or floppies.

Depending on your (or your team's) philosophy, you might want to skip deploying any .PDB files. Do you need to debug on your end user's machine, or need to get detailed call stacks?

Depending on what you are releasing, you may not need to deploy associated .XMLDOC files. They have the helpful information from your embedded documentation for other devs, but if only end users will be targeted, do they need the API docs?

As for how to package all of that up, it depends on your deployment strategy and your target platform/environment.

Often if you are in corporate network and you are pushing to desktops and don't need to set any registry settings or create databases, simple XCOPY deployments will work, and you can just have loose files. Or there is ClickOnce which again in general is just loose files and some versioning metadata. Or if you have a web app that just needs a one time configuration of IIS/NGinx/Apache, you can get away with loose files.

If you need some special configurations in the target machine (registry values, databases, folder structures, permissions, etc.), then look into building a .MSI. Or a MSDeploy package for a web app.

If you need to deploy as a new Windows Store App, you are forced to build using MS's app packaging (unless you have very tech savvy users who are not afraid of the command line).

Thanks SkyDiver.
Here is what I have done, as this youtube video demonstrates (mostly)


In Microsoft Visual Studio 2022 Click Project --> Then click the project name Properties...
On the menu on the left, click "Signing" and click to sign the ClickOnce menifests.

Then click on "Security" on the menu on the left and enable ClickOnce security settings

Then click on "Publish" and then, what I did is select as the publishing folder to be a location on my company OneDrive.

And I clicked on Publish.

THen, as you can with OneDrive, I shared the folder with the application and setup executables with my boss.

But, in the future, I suppose I will have to use the FTP to do this.
 
Back
Top Bottom