This error isn’t related only to FirebirdClient only, but any .NET application that is targeting multiple .NET Framework versions, but I spotted it first during FirebirdClient development.
The error message
Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b77a5c561934e089'. is little bit cryptic. Let me explain how all this mess happened. The .NET 4.5 is in-place update of .NET 4.0. So a lot of stuff looks like it’s .NET 4.0, but it’s not. It’s .NET 4.5. One change Microsoft did in .NET 4.5 was moving the
mscorlib (so they can use extension methods in
mscorlib). So if you build application targeting .NET 4.5 and it uses just plain .NET 4.0 (or even older) it runs fine. You’re fine, user is fine. Until it hits some extension method. Then it tries to locate the above mentioned attribute, but from
mscorlib. On .NET 4.0 it’s not there. Even if the version says
126.96.36.199. Yeah, in-place update.
Problem is, that users (even some developers) are not aware of these minor changes. And because the application runs – at least a while – it’s confusing. :\ The bottom line is – always download/use exact .NET Framework version version of the application/library.
As it turned out the I introduced regression in 3.0.1 while building .NET 3.5 version. It’s now fixed in 3.0.2 and available on NuGet and website. Link to tracker with details.
Sorry folks. :\
Few weeks ago the 3.0.0 version was released (actually it was during Firebird Conference 2012, during my talk ) and it came with some new features and improvements (hence version 3.0.0). And as it goes, nothing is perfect and few items slipped through testing phase. So that’s th reason why today, I’m happy to announce version 3.0.1 to be released.
You can download it from NuGet or from Firebird SQL site as it gets updated.
This release contains fixes for two regressions introduced in 3.0.0. You can see both in tracker. It’s also my initial step to release these small bugfix releases more often (as discussed in list).
Go grab it, while it’s hot.
When we worked together with Aleš Roubíček using Windows Azure cloud, we faced quite a few surprises with applications in cloud. Especially when the application isn’t small and is using a lot of “cloud” services. Sometimes we used hashtag on Twitter for it: #cloudlife.
Last week I was creating fairly simple tool that allows (or should allow) me to copy some files to S3 bucket. I had some special needs because the folder where the files were was heavily changed and the tool needed to handle that. Because AWS has SDK for .NET I was not expecting that to be extremely difficult. How wrong I was.
Every file in S3 has ETag associated. And you will get it with almost every request, i.e. when you’re listing bucket. Good candidate for decision whether to copy the file (because it was changed) or not. The SDK contains
AmazonS3Util class which allows you to compute the checksum/ETag. Great, should be piece of cake. Not so fast. The SDK and S3 itself has some gotchas – #cloudlife.
First the ETag returned from SDK is inside double quotes. But the value from
AmazonS3Util is not. I can fix that. Could be worse. Let’s move forward. For big or huge files the new multipart upload (you are uploading the file in smaller chunks) is recommended. Boom. Checksum/ETag is then different. For same file uploaded “normal” way and multipart the ETag differs. Sadly the
AmazonS3Util can compute only the checksum for “normal” type of upload. Never mind. Next. Every file can have some metadata associated, I can store my own checksum there. I will need to request metadata in separate call, but I can live with that. So let’s use
WithMetadata method to add some key/value. Good no problem so far. Retrieving metadata. Suspicious method
GetObjectMetadata (and the
EndGetObjectMetadata counterparts) returns NameValueCollection, I can probably find the same key as I stored there. Not so fast. My key originally stored as i.e.
foobar is now
x-amz-meta-foobar. Maybe the
WithMetadata could enforce that in input, so I know there’s always this prefix. I don’t like hidden magic. Almost there. Every request is also signed (that’s, also, why we have the key and secret) to be sure the request was not changed on the way etc. (headers, parameters etc. are part or the input for signature). SDK handles the signature for me. Badly. As long as you use US-ASCII characters in filenames/paths or better to say keys for storing the data, you’re fine. Try to put there some “special” characters, like in my case diacritics. Suddenly the signature doesn’t match what’s expected and server will not allow me proceed further. Yes you’re right, the encoding issue. Sadly I don’t know currently workaround. Hope it’ll be fixed soon. Hitting wall every while.
And you know what? Some limitations and challenges I like (ETag issue. These are reasons why I like development and creating software. Some I don’t like (encoding issue), I shows somebody wasn’t doing own work properly. And why #cloudlife? From marketing we’re told the cloud is so cool and so … best, it’ll solve all our problems and we expect it to be perfect. But it’s not. It’s piece of architecture as every other component in your solution. You should expect issues.
Have fun, develop for fun.
I’m pleased to announce version 3.0.0 of ADO.NET provider for Firebird and version 3.0.0 of DDEX provider for Firebird. ADO.NET provider 3.0.0 comes with couple of bug fixes and two major improvements.
- Changed transaction isolation modes
- New installer that updates machine.config
You can read more about the first at DNET-337. Basically now ReadCommitted and ReadUncommited are same. And using (among others)
isc_tpb_rec_version. That should better match the default behavior a lot of people is expecting.
The new MSI installer now not only installs all the necessary files, but also updates
machine.config file and registers the assembly into GAC (you can select not to do it). So after full install, you don’t have to do anything. You’re just ready to go.
The rest of changes can be seen in tracker log for this version.
The DDEX provider 3.0.0 comes with new installer as well. Now when you do the install, the DDEX provider is fully registered into Visual Studio (you can select version(s) during install) and ready to go as well. No need to fiddle with registry or any other files.
Hope you’ll enjoy these improvements.
Fun today. I was trying to use
FirebirdClientFactory from FirebirdClient installed in GAC. Because it was used globally I was not editing
machine.config. I went to
Framework etc. directory and modified
machine.config. And … and it still wasn’t working. Fast forward, I spent maybe an hour trying to figure out what’s wrong. I was hopeless. Everything seemed fine. Randomly cd-ing through directories and thinking what I’m missing, I realized I didn’t modified
Framework64. Stupid mistake.
Sure after I corrected myself everything started working. Hope my story will save you time.