I am really fed up with this error in VisualStudio. Luckily I am not the only one experiencing this problem.
Frans Bouma as an ISV is also pretty anoyed that the fix can't be downloaded directly. Well I always forget to put the hotfix on my usb memory key and have to call (again...) to get this hotfix.
Here is the knowledge base article for those that need some extra information:
FIX: You receive the “Cannot copy assembly” message when you build a c# solution in VS.NET2003
Well that is the formatted message of the following fxCop rule name ExplicitMethodImplementationsInUnsealedClassesHaveVisibleAlternates. Today I had this strange fxCop error that I really had to read about five times before I understood about 95% of the error. This error clearly needed some investigation instead of the usual refactoring with ReSharper (if you use VS2003 and fxCop then
ReFactor is definitaly a time saver!). The error I am talking about is "
Explicit method implementations in unsealed classes should provide alternate methods with protected accessibility". Which is a bigass name to begin with!
So lets read the extra information about this error:
Explicit method implementations are defined with private accessibility. Classes that derive from classes with explicit method implementations and choose to re-declare them on the class will not be able to call into the base class implementation unless the base class has provided an alternate method with appropriate accessibility.
When overriding a base class method that has been hidden by explicit interface implementation, in order to call into the base class implementation, a derived class must cast the base pointer to the relevant interface. When calling through this reference, however, the derived class implementation will actually be invoked, resulting in recursion and an eventual stack overflow.
The problem here was that I had a class implementing an interface method as follows.
A.
void ITest.SomeMethod() { ...}
The interface could also be implemented as the following alternative.
B.
public void SomeMethod() { ...}
In situation A you can't call ITest.SomeMethod from within your implementing object directly. The only way is to cast this to an ITest reference to call ITest.SomeMethod(). I knew that but I didn't need it because I would write the code as in situation B. ofcourse. Funny thing is that I forgot to seal to class and fxCop reminded me to do this with this error. But this means that you should normally just use situation B. as the primary way of implementating an interface. Problems arise when implementing two interfaces that share methods with the same signature but would have different implementations.
Normally I don't seal classes that often but I was working an a class that did some communication with unmanaged resources and had some unsafe code in it as well. It is a device driver wrapper and I wanted it sealed so people would think not twice but a hundred times before changing logic and would make the driver unstable by inheriting from it. We use
IOC a lot at the current project for external resources. Having someone around that change the driver factory configuration to supply a new driver because they would think they can easily add some functinality to it would not really make me a happy person.
It seems that community server has support for articles so I decided to post an old article of mine about how to configure an ipv6 tunnel. The article was written with the xs4all as ISP and tunnel broker. These days I as
SiXXS for my ipv6 connectivity but nevertheless an interesting article. Especially when you want to configure ipv6 routing. The only thing is that it is writen in dutch.
Article :
ipv6 tunnel xs4all windows 2003 (dutch)
Weird thing is that I don't see the articles mentioned anywhere. So it seems I had to add a blogitem to refer to the article thus this post.
Most people use the setup routines supplied with Visual Studio or something like Wise or Installshield to create their setup packages. My current project needed some setup routines and I needed this excuse for sometime to finally see that WiX is all about. Well one thing you don't get is an easy 1,2,3 click and go experience to create your MSI installers.
The stuff you get are basically some command line tools candle, light, dark and recently tallow. Candle is the compiler to create object files from xml input. Light is the linker that does the magic to create an installer or merge module. Dark can decompile an msi which comes in quite handy when you know that some installer of some program has cool functionality in ther setups and last but not least tallow which can create input xml based on the files on the file system. This is very handy in combination with automated builds.
They are currently busy with Votive which is a very interesting Visual Studio add-on that can create easy setups. One of Votive cool features is that acts like a preprocessor. It can replace placeholders in the WiX xml files. This way you can create templates to easily create setup's for small applications. However... it really needs the ability to have 'tallow like' functionality to automatically add all output files. Just as adding some merge modules within a nice gui would be a blessing. I would really like to see those features added in the future maybe I will add them myself when I can 'create' some time.
What do most installers have in common? Generally they have a Welcome screen, an EULA, a destination selection, a full, common or custom selection, progress indication and a result screen. Some applications have the ability to launch the application and/or show the read me when finished. These are quite common for normal desktop applications but when it comes to most applications I work on professionally we need extra functionality. Like to be able to install dependencies as the .net framework, setup a web project, windows services, a database, com+ and/or msmq. Believe it or not but this can all be done with WiX! I got most information to get these thing done is from the excellent WiX Tutorial by Gábor DEÁK JAHN .
What really is cool is the way tallow works. Tallow is a tool to create a wxs xml input file for candle. It scans a directory and imports all files. It is able to add/remove/configure the full range of entities in the COM+
catalog which is still very important because loads of dependencies are still com based and application services are installed in com+. So tallow is my friend as trees are for Bob Ross. The best thing about tallow is that you can merge it into your build engine with for example nAnt. You can create a nAnt task that launches tallow and then let candle compile that output together with a standard template for that specific project type. Then we only need to links all that stuff together and voila there is the msi.
The WiX toolset is very flexible and most things can be customized to suit your needs. One thing I have already learned it that you need to create some good basis WiX templates and use those to create most installer types. I will definitely recommend to use WiX especially within automated build environments.