In my team we create assemblies to attach to extensible released software created and published elsewhere in my company. These assemblies are often specific for an individual client, though some are reused. I want to introduce a couple of standards into this environment - version numbers and installers.
Currently, many assemblies go to clients without adequate versioning. I want to institute automated version number updates so when a client has a problem we can be sure which source code was used in their software.
Currently, assemblies are installed by the individual copying them manually to the correct path and performing any necessary registration. I want to force people to use an installer package so the path and registration is handled automatically.
I could implement the first step by getting people to use:
[assembly: AssemblyVersion("1.0.*")]
But I'd prefer to update the AssemblyFileVersion rather than the AssemblyVersion. This is because I understand that advancing AssemblyVersion combined with our manual installation can lead to multiple versions of an assembly being registered. AssemblyFileVersion doesn't update automatically, and I'm wary of a solution that requires developers install 3rd party tools. If we had a proper installation process, the problem would multiple versions would go away.
For the second step, if I use a Visual Studio setup project then adding the assembly causes it to try to add other assemblies from the original published software, which I don't want. I assume I can create this as a patch somehow, but I've not worked that out yet. Of course, an installer will require reliable version numbers or things will go badly.
It seems clear having written this that I need to advance both issues simultaneously, but I'd really rather approach one at a time.
Any thoughts for the best way to get over these two issues?
I don't have nearly enough information to point you to a solution. What are you using to build your application and installers? Desktop F5 build? Team Foundation Server? Cruise Control?
Things to realize:
1) Visual Studio Deployment Projects suck. Yes, I'll stick by that comment. In your case, the dependency scanning problem you have is unfixable. Even if you right click | exclude the dependency it could scan a new dependency at build time. We even wrote visual studio automation to open the project, right click | exclude everything and then save it on the build machine to avoid this problem. Trust me, it's a horrible road to go down. Even Microsoft knows it sucks and that's why it won't be in the next release of Visual Studio anyways. Use other tools such as Windows Installer XML or InstallShield Limited Edition or Professional.
2) You must update AssemblyFileVersion. This is such a core/foundational tenant of Change Management and it's critical in getting Windows Installer upgrades and patches to work. AssemblyVersion can be changed at your discretion and is only applicable to Strong Naming and IoC scenarios such as Prism where you write rules on what constitutes a valid class for injection.
3) 1.0.* isn't what you want. You want a system that increments your version and passes it into your build automation. What you use will depend on what you are using for build automation. I use Team Foundation Server and a project in CodePlex to do my versioining.
4) You should never be building on a developers machine. You should always be using a clean build machine with automated scripts and not F5.
If these are released applications, then the installer method is fine. If you are adding libraries through this method, and not necessarily the actual application, then something like NuGet (package manager) is an option. NuGet itself is a bit infant and needs to grow up a bit, but I think it should fit your basic scenario.
If you have published software, a bootstrap on the client that calls for updates and then runs the update installer is a good pattern.
The basic answer is you have options, depending what bits you are employing and should take advantage of the one(s) that fit your needs.
Related
I've got a sizable project, with multiple classes, 500+ images, and 20+ text files associated with said project.
I've been publishing my project via right clicking on the project->properties, and clicking on the publish tab. I've included the text files and images as resources already.
The issue is that whenever I install an application, usually it's a simple installer, i.e. you download an installer (one file such as installer.exe), run this file which then takes you through the setup, such as where to install it to, etc. Then the application is installed and that's it.
Well, when publishing my application, I specify an output directory, and I'm left with these files:
Application files
MyProjectName.application (the manifest?)
setup.exe
If I run setup.exe, I'm able to install the application and run it with no issues. However, not only does it not let me choose where to install it, but I would have to send all 3 of these files to the user. I tried to send just the setup.exe to a friend and it said they were missing the files required (which I'm assuming is what the application files and .application were for).
How would I go about bunching these all into one installer, one that more closely matches how you would install an enterprise application (think of installing chrome, eclipse, photoshop, etc)?
I've love to be able to have one file which is the installer and be able to have users download that.
Thank you
The Ancients: If the below is TL;DR (too long, didn't read), please skim these two links:
Troubleshooting Setup and Deployment Projects
Why use Windows Installer XML (WiX) over VDPROJ?
UPDATE: September 2018 - Since this "answer" was recently downvoted, let me try to add some more links to see if the intent of
the answer can be made more clear. Not to be overly dramatic, but:
As deployment specialists we have to warn people when they commit to using a tool that is bound to fall apart for them down the line when more advanced deployment requirements invariably surface.
The installer projects have several times been pulled back and then
re-introduced in Visual Studio. Always based on the problems seen
with these project types (just the bigger ones):
1) No MSBuild support (not tested extensively by me, but by others), 2) only deferred mode custom actions running in system context (not insertable in GUI), 3) highly limited control overall (always advertised shortcuts, no ability to configure certain things, etc...), 4) no support for proper service installation - requires custom actions instead, 5) very few available prerequisites to bundle, 6) rudimentary GUI with little flexibility, 7) appears to not be possible to define MSI features (as in features and components), 8) problems with 32 / 64 bitness issues for custom actions, etc...
An old MSDN page on this project types and its problems: Troubleshooting Setup and Deployment Projects.
MSI Expert Chris Painter and others:
Are Visual Studio Setup projects suitable for complex setups?
Why use Windows Installer XML (WiX) over VDPROJ? (recommended)
In my opinion the project type can only work for simple.NET applications. Any complexity of caliber and you are in trouble. SQL Scripts, IIS, proper COM / COM+, Users & Groups, Shares, Firewall Rules, Custom GUI, etc... Commercial tools and WiX have advanced support for these things. The internals of the compiled MSI files are also sub-standard (use of self-registration, custom actions for services, etc...). I often experience that the tool stops working for "some unknown reason" as well. Suddenly it won't compile. Concrete Example (with fix).
Alternatives:
Simple List View of Deployment Tools
WiX Quick-Start Hints (if the tool needs to be free)
How to create windows installer
(links to all kinds of deployment tools, summary of MSI advantages and
some brief descriptions of trending deployment technologies)
The open source WiX toolkit features a component called
Burn to create such setup.exe launchers / downloaders
/ bootstrappers - used to run several installations in sequence and /
or install prerequisites (a very common task - Visual Studio projects
only support a few prerequisites).
Writing WiX XML markup code is necessary to use this Burn feature.
Commercial tools Installshield and Advanced Installer
provide GUI-features to build such setup.exe files.
The Visual Studio installer is very limited, I never use it. WiX (link to an answer trying to provide some links for a WiX crash course) is a full blown, open source deployment solution. It will take you a while to master, but it is very good and flexible. A commercial solution such as Installshield or Advanced Installer will allow you to deliver a setup faster and easier, but they can be very pricey.
Given the limitations of Visual Studio Installer projects (and bugs), I do believe the right solution is to use a different tool:
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc. If you need anything advanced at all, you will struggle otherwise. With a more advanced tool it is at least possible to do what you need, even if it might be more involved at times.
Let me know what you want to know about such a process, and I will try to help. I am not sure what software you are delivering, what the target user group is, what budget you have, etc... Windows Installer is highly desirable for a number of corporate benefits, but other deployment technologies exist (see the description above of various tools to use).
I'm a little bit confused with the new Installer in VS 2017, I don't have a really good connection, so I want to only install crucial components that I need, mainly for Unity3d C# text editing and debugging along with simple .Net stuff, Xamarin mobile dev (just compatibility, not the tools themselves) and maybe C++ compiling for UE4 source project.
For now I feel the Workloads are stuffed with unnecessary components like .Net Portable Library TP (1.5 GB), older .Net SDKs and Targeting Packs and database tools etc, all mingling within a confusing inter-dependency that I fear to break.
So my question is what are the Individual Components for a bare minimum C# .Net environment for subsequent Unity and Xamarin development and eventually C++.
I would be very grateful for any elucidations, thanks.
One of the goals with the new setup experience in VS2017 is to give you the most streamlined install selections we can fit to your needs. There are 2 ways that features are grouped:
Workloads give a well-rounded experience in a given topic area, with suggested optional features listed (sometimes are selected by default and some are not; you can always unselect these). Workloads are not minimalistic, they are trying to cover broad development areas and offer a simple set of choices.
Individual Components give you a narrower, more specific feature set. Each component still keeps track of (and the setup engine enforces) its dependencies; that is, if you install an IC, the functionality of that feature should fully work. If you try to uninstall an IC, the setup engine will tell you all ICs and Workloads that depend on it, and will prompt to uninstall those as well. The engine should not let you end up in a broken state (that would be a bug).
If you feel like the Workloads are pulling in too much, feel free to skip them and just jump straight to the Individual Components tab. Add the features you think you'll need, and their dependencies should get pulled in as well.
Or alternatively, go back into your install, start unchecking the boxes, and see what the setup engine tells you about dependencies.
From what you've described, the minimum set of components you want will likely be (and some of these may be dependencies of others in the list):
C# and Visual Basic (under the Development Activities group)
Visual Studio C++ Core Features (under the Development Activities group)
Xamarin (under the Development Activities group)
Visual Studio Tools for Unity (under the Games and Graphics group)
You can always go back and add/remove other options as you feel like it too.
Time to ask the pros, since I can't find a good answer anywhere else and I'm venturing into a side of the world that I'm just learning.
I'm in a primarily open source shop that has recently begun taking in a lot of internal tools and partners that are .Net based. That got me to thinking that I may be able to utilize the best of both worlds by leveraging C#/mono in certain spaces. On a small scale I've been very successful and it's working great. However, pressing 'Build' and scp'ing the exe into place isn't going to scale well.
I'd like to step it up a bit and get some more resources behind it, so here's my question; what are the baseline resources I need to establish a good dev/testing/staging environment.
I don't need uber-detailed information and I'm willing to consider both commercial and open source solutions, I guess I'm more looking for good advice on resources. 99% of the items developed on either side of the OS line will be services.
What sort of Unit/Regression testing tools are recommended, is NUnit the standard?
What sort of deployment mechanisms are recommended for service level software?
What, if any, additional tools have you found useful or indispensable during your development/design work?
The first 2 items are of interest since they are the last things I'm lacking before I have workable, repeatable development and deployment process.
You might want to look into http://go-mono.com/monovs/
It will alow you to debug on Linux from within Visual Studio.
The unit testing framework in Visual Studio is rather good as well,
but if you use the standard or free version of Visual Studio, NUnit is a good option as well
(And there is the option of Visual Studio integration)
Aside from that I've come quite attached to Refactor Pro (and other products by that company)
http://www.devexpress.com/Products/Visual_Studio_Add-in/Refactoring/
As for scp'ing the files to your linux/mac machines, it might be easier to
configure MSBuild to do that for you automatically.
This might help: http://bartdesmet.net/blogs/bart/archive/2006/04/13/3896.aspx
Many more msbuild tasks can be found here: http://msbuildcontrib.codeplex.com/
I hope this helps.
For build and deployment you might give NAnt a try. It'll handle your builds, and has tasks for running your tests, doing clean SVN checkouts, zipping up releases, that kind of thing. You can embed C# too. Grab the nightlies rather than the releases and don't worry too much about the lack of recent activity. Also the nant-contrib project is full of additional goodies.
Another option is to try msbuild (I believe there's a Mono equivalent, although I'm not sure to what degree). Truth be told there's not a lot of difference between the two.
I have built effective build/test/deploy infrastructure with the following:
NUnit
CruiseControl.NET (or CruiseControl)
NAnt (and NAnt Contrib)
or MSBuild (depends on your environment)
We also use subversion to manage both source control, as well as deployment (for things like CMS and website systems)
A few of the build tools we use are:
Simian
NCover
NDepend
Powershell (for both build automation as well as deploy automation and machine control)
Of course any of these tools can be substituted for other tools you like (perl, python, ruby, Ant, etc).
This is roughly how I've set up my environment at work:
I use NUnit as a unit-testing platform
I use TestDriven.NET as a plugin to easily run my unittests from within my IDE
I've set up a separate computer, which runs CruiseControl.NET
This CruiseControl.NET computer checks my source-repository on regular times. When it sees that something has changed, it gets the latest version from the source-repository and builds it. It also performs unit-tests, and runs fx-cop over the targets.
Next to that, i've configured it so that it performs a nightly build as well. This does roughly the same:
When something has changed during the day:
remove every file that exists locally
get the latest version from the source repository
build it
run unittests
run fxcop
create documentation using sandcastle helpfile builder
when the build was successfull, copy the build output to a separate folder which is named 'build-yyyymmdd'.
I've setup my source-repository so that I can keep different versions (branches) from my project.
In short, my source-repository looks like this:
I have a folder which is called
'devtrunk', which contains the actual
codebase. (On which I'm actively
developping)
I have a folder calles 'releases'.
Every time I release a new version, I
make a branch of the trunk, and I put
this branch in a new folder under
'releases'. This allows me to fix
bugs in a version that has been
released, without disturbing my
actual work on the trunk.
Since I'm working on the Windows platform, I use MSBuild to create my build-scripts (which are executed by Cruisecontrol), but, you can use NAnt instead. (Which I've used as well).
We are working on deploying a very custom application.
The application is the main program (and only program) that will run on the PC, but it depends on multiple 3rd party installers that must be installed via separate setup programs. Some of these are standard MSI, install shield, other outdated setups, etc.
On top of that we must deploy SQL Server Express 2005, install IIS if it is not found and setup a website.
Our final end user deploying this will be a person with technical experience on a new "out of the box" PC with XP SP3.
What is a good option for developing this? WiX? Visual Studio setup projects may not cut it. There is also the issue of somehow running other MSI's while an MSI is already running.
Would it function better as a standard C# application that requires .Net to be preinstalled? Then it would merely prompt for a few options then run several installers I suppose.
Any thoughts? We'd prefer to stick to C# .Net.
Doesn't XP SP3 already have a .NET runtime installed?
If your end user is someone with technical experience then it seems reasonable to sacrifice some of the "wizardness" of an MSI package for the flexibility of something a little more raw, such as a Ruby script, Powershell script, or .NET console or Winforms app.
This comes down to the benefit vs. cost.
If this is only to be run on a single or small number of target PCs and you have the ability to support the install (even remotely), I would recommend going to a manual install for any 3rd party dependencies.
It will be much easier to provide each package's installer with written instructions and provide than to write/test/debug (and probably still support) a complex, fully automated installer that will only be used once or thrice.
If there will be many installations, the automation will give more benefit.
There is an installer product called Inno Setup that might suit your needs. It allows for custom scripting so you can detect whether all of the dependencies are installed.
If some of them are not installed then with some scripting the installer can download and install the 3rd party dependencies before installing your app. Some help with that can be found at the Code Project article. (http://www.codeproject.com/KB/install/dotnetfx_innosetup_instal.aspx)
The only problem with this route is the scripting language is in pascal.
Just a question, is the company you work for supplying the boxes because if you are then couldn't you pre-install the software? At least that way there is one less thing that can go wrong.
WIX is a fairly flexible way to create the installer (although the learning curve can be quite a bit as the documentation still is lacking). That would probably be your best bet for installing the components that are actually your product's artifacts. Have it check that the required components are installed, but I wouldn't try to launch installers off of it. Instead, like Seth mentioned, write a Powershell script/VBScript (or Console application) that will do the component checking and launch the old installers for user in the order necessary. Of course you would need a way to capture when the installer finishes before continuing on (don't know if VBScript really has that capability, so Powershell/Console app may be a wise choice). And the final installer called would be your product. This way if there's reboots required the installer can be ran the exact same way and would just keep checking for required components and firing off installers as needed.
How can I deploy a C# Visual Studio 2005 project so that I can run the application in another system? My project has a few dependencies and files that have to be integrated while deploying the project.
What is the best way to handle this?
You need to know what dependencies you have.
you need to have .Net framework installed
you have to explicitly install all dependencies that you used from the GAC on your target machine (some 3rd party components)
and then you just need to copy files from your \bin\Release folder
install all services, etc. if you have any
In the simplest cases only copying files should be enough.
Have you looked into ClickOnce deployment?
It's far from perfect, but for projects without a huge amount of overhead, it's generally good enough.
What kind of project?
Assuming it's a regular winforms application, just copy everything from either the obj\debug or obj\release directory to the new computer. Then run your executable
You can right click on the project file in visual studio and publish to a different location. This will build the site and copy it to the specified directory.
Also, if you need to do anything extra during the build, you can specify custom build actions on the build tab of the project's properties.
EDIT: now that I see you added that it's a windows application my answer doesn't matter. I'd try adding a setup and deployment project in visual studio to handle installing/deploying your windows application.
You more or less have three options (maybe 4?) as I see it.
Windows Installer
ClickOnce
Just distribute
the exe itself
In your particular case I would suggest ClickOnce as long as the project is not massive with too many dependencies.
For other alternatives.
The right answer depends on many criteria.
The simplest way to deploy is by copying files. Just put your .exe, the dependent .dll's, and the .config file in a directory and copy it onto the target machine. It's simple, but there are many restrictions to this approach:
It assumes that the target machine has the right version of the .NET framework installed
It assumes a certain technical competence on the part of the person installing the software.
The installation won't do basic things like create start menu items.
Publishing the program for ClickOnce deployment addresses a lot of these issues, but it's got its own set of limitations. I haven't used it much, so there are probably more than these, though these alone are pretty significant:
Programs are installed into the ClickOnce cache, not the Program Files directory.
If your program does anything outside of the ClickOnce sandbox, you have to deal with security elevation and code signing.
You can create a VS Setup and Deployment project and build an .msi file to install the program. The most obvious drawback to this is that it's complicated: .msi files can do many, many things, and the Setup and Deployment object model is complex, with documentation that is, let us say, fanciful. But there are things you can do with .msi installation that you can't readily do with other approaches, including (and certainly not limited to):
Cleanly uninstall the program through Add/Remove Programs.
Provide an actual UI for installation that lets the user decide where to put the program.
Support scripted installation via MSIEXEC.
Install components besides the program, e.g. databases, COM objects, etc.
Put components in the target machine's GAC.