I started to build a new application this afternoon. It's nothing complicated, it just needs to read all the data for the forum on our Intranet and write it into flat files so we can archive it somewhere on our new improved Intranet. I fired up Visual Studio and knocked up a UI - basically it has a Start button and a number of progress bars. Switching to the code, I added a reference to the Enterprise Library 4.1 Data Access Application Block and wrote some code to read the data. Having got to the first point where I wanted to check that things were going more or less as I wanted them, I hit F5 to build and run the application.
The type or namespace name 'Data' does not exist in the namespace 'Microsoft.Practices.EnterpriseLibrary' (are you missing an assembly reference?)
Er, huh? I hit Rebuild with the same result.
I checked that I'd added the block - yep, there it was in my project References.
Rebuild. No joy.
In the immortal words of Kenneth Williams, "stop messing about". I actually fired up Explorer and browsed to the DLL under my Program Files folder to ensure it was there.
Still no joy...
And then I had a flash of inspiration. The default .NET Framework version for the application was set to '.NET Framework 4.0 Client Profile' - what if that was causing a problem? That's caught me out before when I've been playing with MEF stuff. I changed it to the .NET Framework 4.0 full profile, hit Rebuild again and - success!
I solved my problem, but I'm sure I can't be the only one who's run into this one. It's trivial for me to solve because this application will only ever run on my laptop, but for someone who wants to use the Enterprise Library but also needs a minimal footprint when their app is installed, the two things become mutually incompatible. I can't help feeling that when you add a reference by browsing to a DLL, as I did, that Visual Studio should do a bit of inspection on the DLL and warn you if it's incompatible with the framework version you're currently using.