Converting MSI Project from VS2005 to VS2008 - Welcome Back to (DLL) Hell

Just a few lines to outline something I've recently found out about converting msi projects from vs2005 to vs2008.

After upgrading to VS2008, we've been trying at work to convert everything to 2008. Everything built straightaway, "happy days", we thought.

Comes the first release of THE legacy product we start realizing something is not quite right - the msi is not overwriting all the dlls packaged as expected (this was the behavior on a vs2005 build, where everything was being replaced independently of the version). Also when spawning an msi installation as another process the installation fails and rolls back (which is a always a good crack).

After a bit of digging, looks like good old MS managed to sneak in and ship with vs2008 a fix to the RemoveExistingProducts sequence for msi projects whit the result that msis do not replace files on a vs2008 build unless the version number of the files is greater or has a wildcard in it (i.e x.x.x.*).

Possible solutions? there's plenty, here we go:

1. Increase the msi project version every release to force an overwrite
2. Increase single dlls versions (as a decent shop should do) where necessary
3. Throw wildcards in all your dlls and go home happy

Great - but this doesn't seem to play quite right with COM interoperability where increasing version numbers or the wildcard trick doesn't seem to serve the purpose.

It's back to DLL Hell all over again, and it's time to get creative.

Good luck (any suggestion appreciated).

[C++] convert std::string to const char * (and back)

Kind of a lousy-ass post but Straight to the point (with UNICODE on):

#include <string>

using namespace std;

//..

//from std::string to const char*

string originalStr("Bunny Colvin Kicks Ass");

const char* cnstCharPtr = str.c_str();

//the other way around

string convertedStr(cnstCharPtr); //as simple as this

 

I found myself googlin' this up a number of times and I always forgot everything soon enough since I don't use it often. I decided to post it as a reference for myself and to increase chances to find an answer for anyone else who might be looking for it.

Cheers

[VC++] How to Convert from CString to const char * and back

Dealing with VC++, this is only one of the painful conversions you could have to perform if you're working with CString and you need to pass down to some function (or whatever) a const char *.

Code-snippet follows (UNICODE on):

CString myString = "bollocks";

char stoneageBuffer[100];
//initialize your stoneage buffer
memset(stoneageBuffer,0,sizeof(stoneageBuffer));
sprintf(stoneageBuffer,"%S",myString);

//...

//back to CString
myString = stoneageBuffer;

Note that %S (and not %s) formatting type switches to the opposite type of character set (UNICODE if MBCS build and MBCS if UNICODE build).

[.NET] VB - C# Type Conversion Differences

There are some basic differences between VB.NET and C# when it comes to type conversion.

In both VB and C# widening conversions are implicit. Widening means that the destination type can represent all the possible values of the source type:

' VB sample
Dim myInteger As Integer = 1
Dim d As
myDouble = 1.007
myDouble = myInteger
'Helluva Implicit conversion allowed

// C# sample
int myInteger = 1;
double myDouble = 1.0001;
myDouble = myInteger;
//Implicit Conversion
//allowed

For narrowing conversion - let's say assigning a double to an int, when the destination type cannot represent all possible values of the source type - things change: you need to explicitly cast in C# while in VB the conversion keeps being implicit (don't come asking for an example plz... ).
If you want VB to behave as C# in case of narrowing conversions you have two options: either write at the very top of the code Option Strict On to enable the option at page level, or set the same Options Strict from the project properties to enable it at project level.

This difference reflects VB's wannabe-user-friendly attitude that often ends up messing-up things for people who's learning; but since every .NET developer is called once in a while to do some quick and dirty job using VB (there's a whole lot of frightening VB code out there) we certainly gotta deal with it.

That's all - Kick ass.