As autumn is upon is, it reminds me that it is once again time for Twin Cities Code Camp on October 19th, 2013. This time I’ll be doing a presentation on using BizTalk’s rules engine from .NET clients. There are a couple of articles on this site regarding the topic, but this presentation will be updated to use Visual Studio 2012 and BizTalk 2013. We’ll also have an overview of BizTalk and the Business Rules Engine (BRE) for the uninitiated in BizTalk lore. You’ll find an overview here.
I’ll be presenting my talk at 2:15 PM on October 19 in Room 56 in Rapson Hall on the University of Minnesota campus in the Twin Cities. Code Camp always features a number of great sessions. You may register here. And as always, it’s 100% FREE!
A team member and I were having a heck of a time a couple of weeks back as we tried to make use of a new method added to a POCO class that Ravi created.
For what appeared to be no reason (at the time), the newly created method was unavailable to external classes and assemblies. The code looked something like this:
public class StringOperations
public static string NewOperation(string str)
return string.IsNullOrWhiteSpace(str) ? null : str;
Nothing out of the ordinary here. It’s a pretty simple function–just returns a null if you pass in a null or white-space string, otherwise the string itself. However when this was referenced either by project reference or by referencing the assembly directly, it wasn’t available through intellisense and any attempt to build with a call to the function resulted in failure.
As we were scratching our heads, we tried a number of things you typically do when Visual Studio doesn’t allow you to build code with an external method call, such as:
- Rebuild all the projects
- Restart Visual Studio
- Reboot the machine
The assembly had been deployed to the GAC previously, so we wanted to see if that played a role in our troubles. As it turned out, it did.
When an assembly is in the GAC its definition, for better or worse, is contained there as well and it appears that, regardless of how we’re referencing it, Visual Studio likes to use that version. So in our next attempt we wanted to remove the assembly from the GAC using gacutil like so:
gacutil /u [AssemblyName].dll
Unfortunately, this did not work either. The next thing we tried was to un-GAC the assembly by manually deleting it from the cache. This had worked for me in the past, but it failed here as well.
My colleague then tried using gacutil in a different way. This time, giving a fully-qualified assembly reference, like so:
gacutil /u "[ourAssemblyName], Version=126.96.36.199, Culture=neutral, PublicKeyToken=[thePublicKey]"
Bingo! That did it. Perhaps through the build/re-build and gac/re-gac process of our development, we confused Visual Studio or .NET on our machines. I have no idea. But one more thing to try if you hit the gac/re-gac stage is to use the fully-qualified overload of gacutil /u.
Good luck! I hope it helps!
The first update for Visual Studio 2012 is now available.
Thanks to Jayson Go for the heads up!