When doing an upgrade installation, the old custom actions assembly is first loaded, into the AppDomain, in order to call the uninstall method for the version currently installed. When it’s time for the Install method to be called in the new Custom Actions assembly, it still uses the old assembly since that is already loaded into the AppDomain. This has to do with how the Assembly.LoadFrom method works. This is really bad, not only since the new and perhaps updated Install method won’t be called, but since the old one will execute instead.
Microsoft suggests signing the Custom Actions assembly with a strong name in order to solve the problem, but I’ve tried that without any success. Another solution might be giving the assembly different names for each new installer version, but this seems like a really ugly solution to me.
For more information about this have a look at:
I’m really not sure if this problem is entirely bound to setup projects in Visual Studio and the Uninstall and Install/Commit custom actions implemented as part of an Installer class. I will try to migrate my setup project to WiX instead and see if I can get it work as expected.
For the interested, the Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code. I will tell you more about it in another blog post.
Please try it out and give me some feedback of both possible bugs or features wished for. Make sure to read the included "readme" file for information about what is new.
Code Style Enforcer now comes with a setup program in order to make life so much easier.
I really hope you like this new improved version...
The name refactoring to valid names is not always invoked, in fact it is never invoked for local variables, since not supported by the Visual Studio API.
Code rules from previous versions of Code Style Enforcer must be reconfigured using the installed Code Style Enforcer Configurator application, which can be found in the start menu.
Download Code Style Enforcer.
I will probably publish the beta release this week and rest assured, it has been tested quite alot, I'm using it myself at work. But of course there will be bugs, but I hope you can help me to find those, before the final release.
After this release, I will try to relese CSE more often, with minor upgrades, instead of a huge one like this is going to be.
So please stay tuned...
I thought at least that I could tell you what to expect from the new version, both when it comes to features and bug fixes.
• Code Style Enforcer now comes with an installer to make life so much easier.
• The different rules are now stored as XML files locally to each Visual Studio solution and are added as solution items, in a solution folder that is hidden by default. It is possible to have different rules for different solutions, but it is also possible to share rules between solutions, by linking in the XML files from a common folder. This makes it a lot easier for rules to be source controlled and shared. A windows forms application is also installed, which lets you configure the global default rules that are later copied to new solutions.
• Name rules are no longer configured through regular expressions, but instead with prefix, casing and valid characters. Hungarian notation is not there yet, but will make it into another version.
• Name violations can automatically be refactored to valid names, through a context menu.
• Visibility violations can automatically be refactored to valid visibilities, through a context menu.
• Possible to override violations, by adding an attribute "CSEIgnoreRule" to targets. Why is this a good idea? Well sometimes you simply must have a class called "UTF8", for example, even though numbers are not valid. Then it is nice to be able to add this attribute as an override, which tells Code Style Enforcer that it is a deliberate violation. The attribute also takes a string parameter where one must specify a reason for deliberately violating a rule. This makes it very easy for other project member and yourself to see and remember why the code style had to be broken in that particular case. Another scenario is when always demanding explicit interface implementations, which is not always possible when it comes to data binding or serialization. Therefore it is very nice to be able to clearly specify why a rule had to be violated.
• Destructors no longer report name violations, due to ~.
• Operator overloaded methods no longer report name violations.
• Explicit implementations of generic interfaces no longer report name violations, corrected in DXCore.
• Visibility is now also checked on classes, structures and interfaces.
So what is left to do before releasing this new version? Well not that much really, some heavy testing, but most importantly we have to make the refactoring to name rules stable and hook it up to the standard refactoring mechanism. So look back soon and hopefully the next version will be available.