6

I have a requirement to package up and release a .NET control library across multiple platforms and have a question on how to automate this deployment (or make as efficient as possible) through build scripts and VS2010 configurations.

The control library is to be released as a Silverlight version (separate builds for SL 3.0, 4.0, 5.0) and WPF version (separate builds for .NET3.5 / .NET4.0). I also need to specify release and trial versions of the same libraries. Trial versions will be differentiated in code with a preprocessor statement TRIAL. Both the trial and full version will be compiled in RELEASE mode.

I'm wondering how to achieve this in the most efficient way possible. My VS2010 solution currently has one project for WPF (.NET 4.0) and one separate project for SL (SL 4.0).

  • Do I need to create further csproj projects for the missing versions, e.g. .NET 3.5 and SL 3.0 and 5.0?
  • I wish to create one MSI for all Silverlight DLLs and one MSI for all WPF dlls. Do I need to create further MSIs for the versions compiled as Trial? What about separate MSIs for each version of the .NET or Silverlight framework?
  • Is it possible to achieve the above deployment packaging using build.targets or build scripts?

Basically if I create manually MSIs for all the above combinations and do a full rebuild that would work, but it is also a laborious process when releasing updates. I am looking for suggestions on how to achieve this with build scripts, build.targets, MSI configurations or a combination of the above.

Finally when redistributing the control libraries, installation should ideally result in registration in the GAC.

Any comments / suggestions welcome.

Best regards,

Dr. Andrew Burnett-Thompson
  • 20,980
  • 8
  • 88
  • 178

2 Answers2

2

If you are releasing for different versions of the framework, then you will need different projects. You probably could get away with switching the target framework at runtime, but there are so many variables, by the time you get them all figured out and tested, you could have easily created the additional projects.

I think it would be well worth your money to invest in an Installation tool such as Installshield that has built-in support for the rest of the functionality that you desire.

I believe that you should be able to accomplish all of your needs in a single installshield project using various switches and end user keys (to trigger trial or real installs), but you may potentially consider separating trial and real depending on your licensing scheme.

Update

You can also solve this issue through a pure VS2010 solution, it's just more complicated.

Based on your goals, you will need to have a total of 5 projects and each solution will have 2 configurations, one for release one for trial (where the preprocessor define is set).

You might be able to get away with a single build solution that contains all 5 projects since you can reference the output from each project separately within the VS setup project.

On release, you will have to run the build twice, once for release and once for trial, but you can easily automate this with MSBuild.

What we did to ease the release process burden was create a small database to hold configuration information about the products (locations of solutions, project files, and assemblies) and a small UI application that builds the apps by first changing the version everywhere necessary and then building the installer solution through the visual studio build process.

One very important note that I just remembered as I was typing the above: at one point (it may have been fixed), it was not possible to build Visual Studio 2010 setup projects through MSBuild, which is why we went with building through devenv.com.

competent_tech
  • 44,465
  • 11
  • 90
  • 113
  • Thanks for the information, certainly interesting to know about InstallShield. Ideally im looking for a pure vs2010 solution though. Perhaps setting up different solutions / projects with a rebuild all script is the way to go? – Dr. Andrew Burnett-Thompson Jan 15 '12 at 11:40
  • If you want a native solution, it is definitely possible, just somewhat more work. We actually use a mix of Installshield and vs projects. I have updated the answer with additional information that is hopefully helpful. – competent_tech Jan 15 '12 at 20:59
  • Thank you. Looks v. plausible. I think I'll drop the #if TRIAL and instead have a license key model to switch it at runtime. That halves the number of solutions / projects required. – Dr. Andrew Burnett-Thompson Jan 16 '12 at 09:47
  • That sounds like an excellent plan. Switching at runtime will also provide a much better user experience since they won't have to uninstall, find the release version, and reinstall. – competent_tech Jan 16 '12 at 17:04
0

For posterities sake I'm recording the solution I came up with thanks to competent_tech's very informative answer.

Solved using an msdos batch file as follows.

  • Dumped the idea of #If Trial switch. Instead component is licensed by licx file so trial build is the same as release build. This means just one solution for dev work which build outputs are derived from
  • Created a batch file to rebuild Silverlight and WPF output projects with MSBuild, switching toolsversion to create multiple versions
  • Copied DLLs over to Nuget style directory structure, e.g. Build/lib/net40, Build/lib/sl4, Build/lib/sl5 etc...
  • Obfuscate built libs in place
  • XCopy example projects over to Build/examples/
  • Use Powershell to edit example projects to reference new obfuscated output.

For reference, please see the following questions and answers on removing/re-adding references and editing project files with powershell

Community
  • 1
  • 1
Dr. Andrew Burnett-Thompson
  • 20,980
  • 8
  • 88
  • 178