I had to look again at VS Express, because I'm taking up a new job (moving
them from linux and part MS to all Linux) and part of the move I will have
to look at the few applications that they have on MS.

So I borrowed a MS client from work and downloaded c# and c++ express and
have spent a week with them, these are new versions over those I have used
in previous projects.

There is very little visible that distinguishes them from the previous
version, mostly the differences are to do with the .Net version and SDK
changes. I have to say they are very good, a few niggles, mostly harmless
problems, except for one I have come across that I would say is a very
important problem and gives a touch of insight into current Windows code:-

If you reference the same lib more than once, i.e. via different controls or
classes, then you get violations, given as warnings but they prevent
distribution of your code because what are warnings in a compiler can be
errors in an installer.

In itself it seems reasonable, they are different steps and it has always
been the case that a good compile does not necessarily mean a good install
what ever OS you are targeting, but this isn't really like that, the
problem was neither the compiler nor the installer.

Think of Linux dynamic libs, we reference them all the time from various
places in our code, we might base a class in our project on a class in a
common lib. Then a few weeks/months/years later derive another class of our
own from that same lib. Some time after comes a project that wants both of
our derived classes. Have you ever come across a problem doing that? No,
neither have I, c++ is well able to cope with such things, it's a tree
that's all, but that is really what is happening with the MS libs you
reference, it causes a warning that in turn prevents distribution.

Now add to that. While I was looking at why this happens (I had to destroy
the gui designer on the projects I did this with, back to coding them by
hand). I found that it is a strange internal naming convention that is the
problem. It works like this,

You have accessed one of the libs,
Unbeknown to you at coding time the reference has come via xyz.thislib.dll
The other reference, perhaps you created a control in code rather than
drag-n-drop, via abc.thislib.dll

You could try this out using the media player, treeview or listbox, I did it
accidentally at first with the socket system, but you can go direct, take
one that is a direct reference and another that is an indirect or derived
reference.

The full name of each is what counts in the compiler/linker so
xyz.thislib.dll and abc.thislib.dll are different, but at install it is
only the 'thislib.dll' that is used.

So you are in fact attempting to install two libs with the same name, this
is wrong, remember that the actual base dll's (as in the media player for
example) is the same, but one of the references you used has a bit of extra
stuffing on it, which should be getting installed, the other refference had
no extra stuffing, or had different stuffing (your own code or code added
via the reference source) which also has to be installed.

The reason it can not do this is because the tree is broken, the installer
rightly believes that the items that you are attempting to install with the
same name are in fact different.

That is the key, the system has more than one route to the lib and the
routes are Not the same, the tree structure of classes is in a mess on
Windows.

It doesn't matter that you have something like,

class SomeSystemLib{}

class mylib1 : SomeSystemLib{}

class mylib2 : SomeSystemLib{}

in one project, the base of the two is the same with the extra derived parts
being handled correctly, as Linix compilers do. It isn't a problem in any
stage, compile/link/install.

It can only course a problem if you have something like this,

class SomeSystemLib
{
foo()
{
do something
}
}

class SomeSystemLib
{
foo()
{
something do
}
}

class mylib1 : SomeSystemLib{}
class mylib2 : SomeSystemLib{}
(assuming each got a different version)

But then that too c++ can handle, there has always been a risk of such
things, so you build in ways to spot them or handle them in a well
structured manner.

But it is now a problem on Windows. They are not handled correctly.

And before the Windows fudders come in and say I'm talking bollocks. This is
repeatable, have a go yourself. Use the mediaplayer one because it is
easiest, then go ahead with the treeview, listview, some of the higher
level socket classes. Probably there are more. You have a mix of classes
and the mix is not being handled well at all.

It isn't simply a bug either, it is plain wrong and the reason it is wrong
is because different gaffa tape has been used between your code and the
final lib depending on where you happened to reference your class from.
They are doing it wrong and it can only cause problems, the further and
deeper it goes the more problems it will course.

Oh, and which OS did the machine I borrowed have on it? Vista.