We found a bug in Web Service Software Factory a description can be found here. There has been no updates on it so we decided to download the code and fix it ourself. Very simple bug and we patched it with maybe 3 lines of code. However* we have now tried to repackage it and use it and are finding that this is seemingly an impossible process.
Can someone please explain to me the process of PLKs? I have read all about them but still don't understand what is really required to distribute a VS package.
I was able to get it to load and run using a PLK obtained from here, but i am assuming that you have to be a partner to get a functional PLK that will be recognized on other peoples systems?
Every time i try and install this on a different computer I get a "Package Load Failure". Is the reason I am getting errors because I am not using a partner key? Is there any other way around this? For instance is there any way we can have an "internal" VS package that we can distribute?
Edit
Files I had to change to get it to work.
First run devenv PostInstall.proj
Generate your plks and replace ##Package PLK## (.resx files)
--Just note that package version is not the class name but is "Web Service Software Factory: Modeling Edition"
-- And you need to remove the new lines from the key
ProductDefinitionRegistryFragment.wxi line 1252(update version to whatever version you used in plk)
Uncomment all // [VSShell::ProvideLoadKey("Standard", Constant in .tt files.
The short answer is no, you don't need to be a VSIP partner registered with Microsoft to obtain and use a PLK. The PLK you obtained from the site should work on any VS install. (On a related note, Microsoft has eliminated the requirement for PLK's altogether for VS 2010.)
The following pages should help with debugging what the issue is:
http://msdn.microsoft.com/en-us/library/bb164677.aspx
http://blogs.msdn.com/dr._ex/archive/2006/12/14/debugging-package-load-failures.aspx
There is also a tool in the Visual Studio 2008 SDK called the Package Load Analyzer that should help you debug the load failure (and confirm that it's actually a PLK issue and not something else). Copy and run VSSDK_PLA.exe (under VisualStudioIntegration\Tools\Bin under the VS SDK install location) to your test machine to install the Package Load Analyzer tool.
You don't have to worry about package load keys when rebuilding the Web Service Software Factory because it is a guidance package that depends on GAX, which has the only PLK needed. To build guidance packages, like the Service Factory, you also need to have GAT installed.
The Service Factory source should contain the setup projects you need to build and redeploy it. If you have an issue, the discussion forums on its community site (http://servicefactory.codeplex.com) are monitored by team members. Response is pretty good.
Aaron is right that this whole story gets a LOT easier in VS2010. VSIX is pretty sweet. We are updating the Service Factory to VS2010. It should be ready for release within a month.
Don
MS p&p
Related
Situation - We have a .net mvc solution with WCF layer. the solution has about 20 odd projects that get compiled into DLL. the site is running on SQL server 2008. we maintain the SQL scripts in the solution folder as versions. So we have SQL scripts eg. version 1.0.0.0 to lets say latest which is 3.0.0.1.
the solution is source controlled in TFS, we also use TFS to manage the work items, bugs etc etc. SQL script files are also in TFS
Question - the question is that do we need version numbers on the assemblied i.e. dlls aswell. Our DLLS are not exposed in any way or from to the outside world they are just in the runtime of the mvc app. we do not expose the WCF to outside clients,again its just used by the mvc app.
the deploy process is simplly the latest code against the latest db, so when we deploy we check what version the db is in and run a tool to upgrade it to the latest version that is in the db project in the solution.
One of our senior architects is saying that we should maintain the version numbers in the assemblies aswell. I am saying that we dont need any version numbers in the code. beacuse TFS manages that. when we release we just deploy the latest code with the latest assemblies/ deploy package.
I have not come accross the assembly versions unless them assemblies where released to the outside world (if you know what i mean)
please can you suggest... Also note we dont do feature development its just version numbers so that we know what version a particular DB is at.
I would prefer the security of knowing and being able to double check versions. If there were a problem with the publishing process, or there were a bug that manifested itself that appeared to be a publishing problem I would want to rule things out as quickly as possible. I also think that it's so easy to implement you've spent more time discussing and thinking about it than you would have actually spent doing it, and there is no down side to it that I can think of.
In a similar project at my job, we use version numbers.
Every commit against the version control system (VCS) causes our CI server (TeamCity) to build a new artifact, with the version set to "LATEST". Every successful build of "LATEST" get deployed automatically to our test environment. We could, in theory, also deploy this "LATEST" version to production, but we don't.
When we want to deploy a new version to production we run a different, manual build job which creates a versioned release (e.g. 1.4.7). The build job also creates an SVN "Tag" of the current codebase. To have our DLLs have the appropriate version, we use TeamCity's AssemblyInfo Patcher feature. This way, we don't have to constantly manually update our projects' AssemblyInfo.cs files. Instead, they get to always have placeholder version info like this...
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]
These number get automatically updated during the build by TeamCity. The versioned artifacts (which include any corresponding SQL scripts) are saved to our "Releases" directory where we keep all our versions of the codebase.
Now this all seems like overkill, right? Not really.
This gives us the following benefits...
Our deploy process does a wget to our monitoring page which lists the version number and asserts the versions match up (version expected to have been deployed vs. the version currently running on the server). This gives us confidence that our deploy process worked properly.
If bugs are found in the versioned release (the production release candidate), we can SVN checkout the tag, apply a fix, and create a new release without having to worry about other changes on trunk which could compromise the release. It is hard to stay "releasable" all the time, this allows to not have to be. Although, don't get me wrong, it has it's advantages.
If problems are found with a versioned release but they can't be resolved quickly, you can always just re-deploy the older artifact which is known to work. Being able to revert a deployed release to an older version has definitely saved us on a couple occasions.
If bugs are found on production that need to be investigated, we are free to deploy the same versioned artifact to any of our test environments so that we can try to reproduce the problems outside of our production environment.
There are probably more advantages I am forgetting at the moment but the above list should give a general idea of the power that proper version management can bring to the table.
What I would advise against is continuously, manually updating 20+ projects' version files. This seems like a lot of busy work which is mostly a waste of time because it is prone to human error. Whatever you decide to do, automate it and verify the results.
The application I'm talking about consists of vb6 (80%) and c#, .Net Framework 4.0 (20%).
All new components are created with c#. With Microsoft Interop Forms Toolkit 2.1 we create the COM UserControls that we later embed in vb6. For Forms we use normal classes to create and open in vb6 (COM Visible project).
To create the setup we use wise.
Locally everything works fine - The problems only occur when we install the application on a non-developer machine with the wise created setup.
We added a class to open a c# Form to an existing interop toolkit project. It works fine on the developer machine and also when we make a new installation on a pc(non-dev-machine). The new class is just used to open the form.
But when we update our application to a newer version, that class is not working anymore. We have to uninstall the old version and install the new version to make it work again.
Anyone had a similar problems before?
I'm grateful for any advice
This seems like it is an issue with Windows Installer and the sequencing during the upgrade. Does your application allow side by side installs (e.g. Version 1 and Version 2 can be installed at the same time) or does your installer upgrade earlier versions to the latest version? You might try logging the installation and reviewing the log file to see exactly what is happening during the install / upgrade process.
You can log an msi installation by invoking Msiexec from a command line.
This may provide greater insight and help focus your efforts to debugging the problem.
Edit
From what you've described it seems that on fresh installation the install works as expected. When you upgrade earlier versions it would seem that the COM Interop components are not registered properly. This could be an indication that the sequence of events is a little off with regards to when the components are copied to the machine and registered vs. when the existing product is removed. While not exactly identical, see this SO Question and answer for more details. Also, have a look at the RemoveExistingProducts action in Windows Installer for more information.
I would log an installation that you know works without issue (e.g. on a "clean" machine) and then log an installation that you know will fail (e.g. an upgrade) and then compare the two log files using a tool to see if the output is identical. If not, that gives you a clue as to where to look. If they are identical it might be time to engage with the vendor and see if they can assist with determining what's causing the issue.
I would like to create a patch for my .NET application. The requirements are:
Find the installation directory
Overwrite the old files with the new ones
Restart a windows service
I want to send the updater to the user so that they simply run it and update the application. My original installer is created using Visual Studio Deployment Project.
I did alot if research, and found this:
https://stackoverflow.com/questions/3767/what-is-the-best-choice-for-building-windows-installers
How to Update the installed Window Application (Creating Patches)
http://wyday.com/forum/viewtopic.php?f=1&t=245&p=793&hilit=offline+install#p793
http://www.advancedinstaller.com/user-guide/tutorial-patch.html
I tried created another installer which would just contain the files I need to replace, however I could not find a way to determine the installation directory of my application.
WyBuild seemed like a good solution, however they do not support an offline install and require you to host the update files on the server.
I tried creating a patch using Advanced Installer but it just generates a bunch of build errors that I could not fix.
There are tutorials how to modify the MSI files using Orca or WIX, but that seems alot more complicated than it should be.
I am tempted to roll my own but I am not sure how to go about it, and this seems like such a basic requirement that there's got to be a solution out there already.
If you already use a a VS Setup Project you can deploy the new version of this project and it will upgrade existing installations. Have a look at the setup and upgrade ids. The stop and start of the service can be done by custom actions that can be defined in the project and will be executed i.e. when your setup is committed or rollbacked etc.
I have Visual C# 2008 Professional and have developed the first half of a C# application (console mode) with the second half in progress now (GUI).
I'm looking for an easy path to creating an installer for it. What are the steps that need to be taken to produce a professional installer?
There's a similar question here regarding the Express edition but I have Pro, and I would like as much as possible to stick with just the standard VS stuff (if you think you can convince me that a third party installer creator is much better than a VS-only solution, give it a shot, by all means).
Keep in mind that I have no interest in upgrading to VS2010 yet, even if it's a hundred times easier to create an installer. That can come later, when the revenue starts rolling in :-)
Also be aware that the GUI component of this application is a totally separate executable from the console part. The console part is a simple "open file 1, do some work on it, write file 2" type and the GUI is a fairly standard "open file, do some stuff" beast so there's no tricky or wildly undocumented behaviour happening.
Basically, I'm looking for (at least) the following:
professional looking installer.
ability to specify where the application files go.
changes to the registry to allow double-clicks on my file extension to open the GUI app with the file as an argument.
needs to install everything required (my stuff, .Net if required, and so on).
This might be a bit more rant than answer but here it goes.
If there is one thing severely broken with Windows client software it is the deployment of applications.
My experience comes from working on NovaMind - Even though I have spent weeks over the years on setup issues, I am by no means an expert in setup technology and I try to focus on our actual product whenever possible. We have used InnoSetup, Visual Studio Setup Project 2008/2010 and finally we have switched to the WiX + Tools approach.
How do you install an application nowadays?
Web Apps: Enter a URL in a browser to get to a web app.
Mac: Drag the downloaded file (same for x64 and x86) to the Applications icon on the Mac. Done.
Windows: Download the right file (user needs to know about x64 and x86 architecture), execute it. Click ‘Next’ a dozen times, wait for the UAC to show, click yes and then hope that the installer did the right thing.
I think that if Windows had a better deployment system, a sane marketplace/app store and a proper live update feature, web apps might never have gotten that popular in the first place. Of course that’s an exaggeration but I believe a lot of damage has been done to the Windows applications ecosystem by not providing a sane, usable deployment model and even now Microsoft seems to pay very little attention to this problem.
How do you update applications nowadays?
Web Apps: No need. It is up to date.
Mac: No inbuilt magic but there is a widely used and powerful solution called Sparkle.
Windows: You better roll your own because there is nothing substantial out there.
ClickOnce should have changed all of this but failed to be usable for real commercial applications.
Here is the rundown:
InnoSetup and other script based installations are simple but cannot produce a .msi file — Some companies require .msi files to automate network deployments. You will also need to have a Windows Installer (.msi) based setup if you want to get the Windows Logo certification.
Visual Studio Setup Project 2008/2010 gives you the basics easily and you can configure a bunch of things but once you want to do the unthinkable like use a high quality icon or include a changing set of files into your setup, you’re screwed. We also had to manually fix the PackageCode and ProductCode every single time we built an update since Visual Studio managed to somehow mess up the assembly versions and would leave an older assembly when updating, thus corrupting the application.
WiX is the de-facto way to create setups on Windows and even the Microsoft Office Setup is supposedly created with WiX. WiX is not simple. There are books available for WiX!
Unfortunately, WiX alone is still not a good solution. We use the dotNetInstaller bootstrapper project to ensure the .NET Framework is installed and to wrap the .msi file and the bootstrapper into a single .exe file that people can download.
With all this you are mostly fine. There are always strange cases were customers don’t have the Windows Installer installed (and thus cannot run the embedded .msi file) or where the .NET Framework installation fails.
Things we haven’t been able to do so far:
Localizing our installer!
Providing a single download for both x64 and x86 — at the moment we only create a x86 installer because we don’t want our users to think about x64 vs. x86.
Have a nice setup UI that also works with high DPI settings. I think this might just be a thing that is not supported in MSI setup.
There is a free product called SharpSetup which seems to address some of these problems and allows you to write a Winforms based UI, but SharpSetup does not come with a bootstrapper and requires the .NET Framework — you can however write your own C++ code to react in this situation.
For live updates we have rolled our own solution and after many issues it is working okay.
You might also want to listen to Scott Hanselman’s podcast episode with Rick Brewster were they talk about the setup and deployment of Paint.NET — While I congratulate Rick and the Paint.NET team on their good setup, the necessity of such a complex solution saddens me.
If you absolutely need to use .msi then I would recommend WiX to anyone who wants to create an installer on Windows, but in the end I am extremely frustrated with the deployment situation on Windows. I have wasted weeks of my time over the years with silly setup issues. With setup you can only lose. You won’t win any happy customers because your setup works but you will lose and frustrate a lot of them if it doesn’t.
Another option is using Inno Setup. It allows you to fully customize installations, where to stick files on the target machine, modify the registry, and all that jazz. If you're willing to spend a bit more time learning a bit about the scripting required to achieve the results you want, it's a very powerful tool. (fulfills all of your requirements and much more) And most importantly, it's free =)
I've been using Inno Setup for all of my larger .NET programs. When the installer runs, it checks to see if .NET is installed and if not, downloads and installs it. As well, I've modified registry and made associations with extensions like you mentioned. Including DLL's with the installer is simple as well - Inno will lump all of the required files into a single executable that takes care of everything.
Additionally, since Inno has been around since 1997, a number of editors have arisen that help make the scripting process a lot easier.
I use Advanced Installer, it is dead simply, and I use it, because of the limitations of VS.
http://www.advancedinstaller.com/
The "downside" is that for fully automatic installation of dependencies you have to pay ;-)
If you want to create your installer fully in Visual Studio, but don't mind using external tools to help you in that job then have a look at a program of mine called SharpSetup. It allows you to build GUI using C#/WinForms, whereas backend is WiX based (which in turn means using WIndows Installer).
Visual Studio 2008 has built-in setup/installer support.
Add a new project to your solution, and select the 'Setup Project' option from the 'Other project types > Setup and Deployment' category.
Have a look at Windows Installer Deployment overview, and a step-by-step walkthrough
If you know scripting languages you can check out NSIS as an alternative to VS. There's enough documentation that you can copy paste their example installer and replace their file locations with your own.
While I'm not install expert, I've used Wix successfully. It's complicated to say the least.
I don't see any of these products being mentioned that I've seen clients use successfully.
http://www.installaware.com/
http://www.flexerasoftware.com/products/installshield.htm
http://www.wise.com/Products/Installations/WiseInstallationStudio.aspx
All provide localization, file/app for double click association, Framework bootstrapping and target location to the best of my knowledge. InstallAware and Wise provide some form of autoupdate support.
I am working on VS 2008 and 3.5 framework.
I had three windows services.
I placed all three in a single solution, created installer individually for each of them.
Then created a setup project.
When I build it says build failed .
But I checked on the errorlist, (i enabled the diagnostics in options menu), but there was no error at all.
I went ahead and installed. There were no issues, But there was no service showed up in the services.msc.
I installed each service individually , using installutil command, it showed up.
But my requirement is to bundle these services and deploy to the client.
The client should install it.
Where am I going wrong.
Any inputs will be highly appreciated.
Regards
cmrhema
I notice your comment above about omitting the custom action. Same mistake I made! For posterity, here's the entire process:
Make sure you have added the project installer to your service project (described here). These components give your service EXE the ability to register itself with the service manager.
Add a setup project to your solution.
Add the primary output from your service project to the setup project (described here). This puts the binary into the application directory.
Add a custom deployment action to your setup project containing the primary output from your service project. This looks like a repeat of step 3, but what it's actually doing here is registering your service with the service manager.
This walkthrough goes through each of these steps in some detail.
I too have a similar problem with VS 2008 and I believe it is a bug in the IDE rather than anything you're doing wrong.
Basically what happens is that VS reports a failed build, but does not indicate any reason for the failure. I find that restarting Visual Studio and then performing another build allows the build to succeed.
I read somewhere that for some people the bug is caused by some auto-created project file, but a restart fixes the problem for me.
Build failed -> what else is there in the Output window?
For some general reference regarding setup projects for windows services in .net:
http://msdn.microsoft.com/en-us/library/aa983650%28VS.71%29.aspx
http://support.microsoft.com/kb/317421