MSBuild, assembly dependencies and the GAC

Today, while doing some .Net development I noticed something about MSBuild that is really annoying.  I’ve seen his before but didn’t know the reason behind it.  Now I do and it is a little frustrating.

If you have assembly A that depends on assembly B that depends on assembly C and assembly C exists in the GAC (Global Assembly Cache).  When assembly B is copied into assembly A’s “bin” directory during build, assembly C is not copied, even if you specify that assembly C is a “private” (copy local) dependency of assembly B.

The problem is that by default MSBuild’s ResolveAssemblyReference task will not copy referenced assemblies that are in the GAC to the build output directory unless the referenced assembly is specifically tagged as “private” by the build project being built.

So even though assembly A doesn’t directly reference assembly C in its code, it only uses C through the intermediate dependency B, you still need to add C to A’s referenced assemblies set for C to be copied into the build output of A.

There is a discussion of this issue here, on Microsoft’s developer forums.

Advertisements

Programmer Humour.

Call:

How do I update controls on my UI thread from the Asyncronous Delegate? I understand it’s not safe to just try to update it directly from the asynchronous thread, but I need to figure out how to update it somehow. Specifically I need to increment a ProgressBar and update text in a Label.

Thanks,
Michael C.

Response:

My name is Tyrone Hernandez. I grew up on the streets, so I’m familiar with this kind of shiznit. I am down with this, and I’m going to keep it real by top-posting.

In my hood, I have a homie named Shaniqua and some times she calls me on the phone in an asynchronous fashion. Now I’m hip to her jive, so I don’t wanna just hang up. If I feels like talkin to Shaniqua, I talk to her. If not, I use my power of “Control” to check “IsInvokeRequired” and if it is, I call Control.BeginInvoke() to upgrade my progress bar.

Well, I’d be likin’ to talk more, but my crack dealer is here so I’m going to call some of his methods. Peace out!

Made me laugh. And he’s correct. Found, here.

Be explicit.

What happens with this C++ code?

class Foo
{
public:
	Foo(bool myDefault = true): default(myDefault) {}
	bool default;
};

void FunctionFoo(const Foo& foo)
{
	if(foo.default)
		cout << "default";
	else
		cout << "not default";
}

void main(){
	Foo* pFoo = new Foo(false);
	FunctionFoo(pFoo);
}

Any guesses?

Well it prints “default”. You may have expected it to print “not default”. Why is that, you ask?

Well, what happens is that in main FunctionFoo() gets passed a default constructed version of Foo. Not the Foo instance pointed to by pFoo. Quite a subtle bug I think. Especially because the compiler says nothing. How do you fix this problem. Easy. Put the keyword “explicit” in front of the constructor.

This has to do with the fact that C++ will implicitly convert parameters to methods/functions whenever it feels it can. See Effective C++ Item #18.

In C++ it is possible to declare constructors for a class, taking a single parameter, and use those constructors for doing type conversion. For example:

class A {
public:
	A(int);
};

void f(A) {}

void g()
{
	A a1 = 37;
        A a2 = A(47);
        A a3(57);
        a1 = 67;
        f(77);
}

A declaration like:

A a1 = 37;

says to call the A(int) constructor to create an A object from the integer value. Such a constructor is called a “converting constructor”.

However, this type of implicit conversion can be confusing, and there is a way of disabling it, using the keyword “explicit” in the constructor declaration:

class A {
public:
	explicit A(int);
};

void f(A) {}

void g()
{
	A a1 = 37; 	// illegal
        A a2 = A(47); 	// OK
        A a3(57);	// OK
        a1 = 67;	// illegal
        f(77);		// illegal
}

Using the explicit keyword, a constructor is declared to be “nonconverting”, and explicit constructor syntax is required:

class A {
public:
	explicit A(int);
};

void f(A) {}

void g()
{
	A a1 = A(37); 	// OK
        A a2 = A(47); 	// OK
        A a3(57);	// OK
        a1 = A(67);	// OK
        f(A(77));	// OK
}

Note that an expression such as:

A(47)

is closely related to function-style casts supported by C++. For example:

double d = 12.34;
int i = int(d);

While I “knew” this stuff, I’ve been bitten by hidden bugs due to implicit converting constructors a couple of times recently so I thought I’d share it just in case others were not aware or had forgotten.

I highly recommend using the explicit keyword on all your single parameter constructors unless you explicitly want to use C++’s implicit conversion feature. Personally I think this is a broken language feature. 99% of the time you don’t want implicit conversion. When you do you should have to specify an “implicit” conversion constructor eg:

class A {
public:
	implicit A(int);
};

But I’m not on the C++ standards body so I don’t get to make those decisions.

Why compiling your code in GCC is a good idea.

Sometimes Microsoft’s C++ compiler just produces bad binaries.

At the moment I’m working on code that compiles just fine using the Microsoft C++ Win32 & Xbox 360 compilers. However it does not run. It crashes during static initialization deep inside the C runtime library. It crashes hard well before the debugger can even load the debug symbols so I don’t even know in where it might be dying. It crashed the Xbox 360 so hard it crashed the IDE.

This is no fun to debug.

GCC on the other hand won’t even compile my code. I’ve been a very bad boy in many spots without even thinking about it and the Microsoft C++ compiler hasn’t complained. At all. Not one little bit. I’ve even got warnings cranked all the way up.

Now after running GCC over my code until it is satisfied that I’ve been a good boy, I compile my code again with Visual C++. This produces a working executable and I can get on with my job.

GCC FTW.