ClickOnce is great technology. Publish your application to a web site or network share, and users click a link in a web page to install your application in Windows as if they were installing a browser plug-in. Publish a new version of the application, and your application will tell the users about it. Then, they can opt to install the new version or skip it. If they install a new version and don't like it, they can use the "Add/Remove Programs" control panel to roll back the application to the previous version. To fellow employees at my company—my users—installation and updates of my application have worked without incident, and everyone likes the process.
However, a complication occurred on my end. After publishing my project to a network share, Visual Studio 2005 began showing an error during the build process. Perhaps you know the error, the one described in knowledge base article 907757:
Error MSB3113: Could not find file 'Microsoft.Windows.CommonLanguageRuntime, Version=2.0.50727.0'.
The article says that this is a bug in VS, and the workaround is to use a file reference instead of a project reference to your Windows Forms project. However, I could not accept using a file reference. I'd have to change it whenever I changed solution configurations because the file reference could only point to one configuration's output. Plus, I did not find a way to implement conditional references. Fortunately, I found my own workaround that allows me to continue using a project reference.
According to the article, project references to a Windows Forms project cause the error, and in my solution, two class library projects each had a reference to a Windows Forms project. The class libraries used the business classes I had added to the Windows Forms project, so I moved the business logic into a separate project. Then, to the other three projects I added a reference to the new project. As a result, I have business logic seperate from UI logic, and my build no longer has the error.
I had to think hard about how to do this, but this works. Basically, like your suggestion says, I had to think about what was going on and correct some architectural mistakes that I had made. Thank you so much, this is SOOOOOOOO much better than a file reference because even if I rememebered to make the switch for each release build, after I left (I'm a contractor) my reputation would be tarnished because the next time the client did a build, they would get it wrong. Thank You! Thank You! Thank You!
ReplyDeleteI had success in the past with using $(Configuration) VS variable inside a path hint for a reference. You have to edit the .csproj file by hand, but it stays untouched in the XML as long as you don't touch the reference itself.
ReplyDeleteThanks. I hadn't thought about using a path hint. However, I'd prefer not to hack the project file if it meant holding onto a poor design, as was the case for me.
ReplyDelete