How to Remove a Custom Component from the Global Assembly (GAC)

How to Remove a Custom Component from the Global Assembly (GAC)

Okay, so you might be laughing right now, as this seems simple and straight forward–and it is, really, once you know how to do it. But for the life of me, I could not find a single resource online to walk me through removing old custom functoids from the GAC. I have been rebuilding functoids that other developers have created, in order to add functionality. For example, the Improved Context Accessor functoid. (Also, my co-worker and I are developing a SQL executor functoid, so stay tuned) Over the course of development, I have added, removed, added, removed countless .dlls from the GAC.

Enter the difficulty. As most people know, you can GAC a .dll for a custom functoid by saving the .dll to C:\Program Files (86)\Microsoft BizTalk Server 2010\Developer Tools\Mapper Extensions, opening the Visual Studio Command Prompt, and using the command

gacutil -i "C:\Program Files (86)\Microsoft BizTalk Server 2010\Developer Tools\Mapper Extensions\functoidname.dll"

And to remove the  custom functoid, the code should be:

gacutil -u "functoidname.dll"

Or, so I thought. But this does not actually work, as the Visual Studio Command prompt will not be able to find that .dll. Most sites told me to look in the C:\Windows\assembly folder for a list of all the deployed assemblies. However, none of my functoids were there.


After more looking, I found that .Net Framework 4 applications deploy to a different location: C:\Windows\Microsoft.NET\assembly\GAC_MSIL If you look in that folder, you will see a list of all your custom functoids. Now, how do we uninstall one? You cannot right click on it and uninstall as you can in C:\Windows\assembly. You still have to use the Visual Studio Command prompt. Take the same of the folder your .dll is stored in, and perform the same code as above. This is what mine looked like:

gacutil -u "BizTalk.MapperExtensions.functoidname"

Notice, I am not using “functoidname.dll”, but “BizTalk.MapperExtensions.functoidname”, as that is how it appears int he GAC_MSIL folder. And that’s it! You will no longer see that tool in the assembly.

Note: If you have an updated functoid with the same name as one that is already deployed to the GAC, you will not need to un-deploy the old one before deploying the new one. The new will overwrite the old.


Improved Context Accessor Functoid

Improved Context Accessor Functoid

Remember the Context Accessor functoid I wrote about in this previous post? I ran into some limitations–namely, the fact that you cannot output the functoid to any other functoids, only a target field. Well, Chompers also found this issue to be frustrating, and found a workaround. He recommended making two changes in his post on the codeplex site. Since the Codeplex source code has not been updated with his recommended  change, I went ahead and downloaded the source code, made the changes, and rebuilt the code. Here it is:

You can find the DLL in /ContextAccessor/bin/Debug

Now, for those that don’t know how to use this functoid, there are two ways:

  1. Maps used in a Receive Port
  2. Maps used in an Orchestration

Maps used in a Receive Port

  1. Grab the .dll
  2. Save the .dll to \Microsoft BizTalk Server 2010\Developer Tools\Mapper Extensions
  3. Save the .dll to \Microsoft BizTalk Server 2010\Pipeline Components
  4. GAC both assemblies
  5. Add the functoids to your functoid Toolbox
    • Toolbox>Right Click>Choose Items…>BizTalk Mapper Functoids
  6. Drop the functoid into your map, and configure it
  7. Add the ContextAccessorProvider pipeline component to your pipeline Toolbox
    • Toolbox>Right Click>Choose Items…>BizTalk Pipeline Components
  8. Drop the ContextAccessorProvider pipeline component into a pipeline at the ResolveParty stage
  9. Build and deploy! Be sure to use your custom pipeline, and apply the map in the receive port

Maps used in an Orchestration

  1. Grab the .dll
  2. Save the .dll to \Microsoft BizTalk Server 2010\Developer Tools\Mapper Extensions
  3. GAC your assembly (if you already did this, you do not have to do this again)
  4. Add the functoids to your functoid Toolbox
    • Toolbox>Right Click>Choose Items…>BizTalk Mapper Functoids
  5. Drop the functoid into your map, and configure it
    Screen Shot 2013-02-20 at 11.05.35 AM

And that’s it! If you have any questions about using this, just post a comment, and I will get back to you. I want to make it clear that I did not write this code. I just made the modifications that Chompers recommended, and re-posted it so others could use it without having to get into re-building the functoid in visual studio. Thank you to Marvin Smit and Carlos Medina for creating these functoids to begin with.

Please leave a comment if you downloaded and used this functoid. I would love to see how it helped you out!

BizTalk Configuration Manager Won’t Load

BizTalk Configuration Manager Won’t Load

This is a response to this thread on the MSDN BizTalk forum.

This is going to be a short one. In summary: this must be a BTS error that has yet to be solved. Each time I tried to run the BizTalk Configuration Manager, I got an error saying another instance was running. I spent hours searching for running instances, repairing my BizTalk instance, restarting my computer. This continued when I tried to run normally, or as an administrator.


Never found a simple one. I had to reinstall BizTalk (what a pain!), but even when I tried to uninstall, the configuration manager stopped the uninstall, saying another instance was running! So how did I uninstall? Microsoft Fix It. I had to use it to forcefully uninstall a few components of my BizTalk instance.

So, say goodbye to a productive work day, get your favorite drink, and try not to stress out while you wait through countless progress bars.


After some time on my fresh install of BizTalk, I started getting the same issue! But never fear, I found out how to overcome the issue this time — the solution is ridiculous and makes me want to yell at Microsoft. Here it is:

  1. Open BizTalk Server Configuration
  2. When the window pops up saying another instance is running, hit OK
  3. Open BizTalk Server Configuration
  4. When the window pops up saying another instance is running, hit OK
  5. Open BizTalk Server Configuration
  6. When the window pops up saying another instance is running, hit OK
  7. Continue to repeat steps 1 & 2 until BizTalk Server Configuration opens up

Why does this work? You tell me. But it does.

The Context Accessor Functoid

The Context Accessor Functoid

First, I want to thank all the programmers in the world that blog, post to forums, comment on forum posts, and make my life easier. This is part of the reason I started this blog–to give back to the community that makes my job easier.

I present to you: the Context Accessor functoid

This little guy is a life saver. For my current project, we are joining two files (an EDI and a Rider) together based on the authorization number. However, it is possible to have multiple versions of an authorization come into the same batch of files–a problem that causes cross joining, and very large files that our target system cannot read. The reason is, a single authorization can come in as a Deny, Pend, or Approve, and each one of these authorizations has the same authorization number.

Question: If authorization number is not a good unique value to join on, what can we use?
Answer: Authorization number + original file name

Part of the original file name is a unique time stamp for each pair of EDI and Rider. With the authorization number + original file name, we are able to consistently join these two files without any cross joins/duplications.

Here’s how it works:

The Context Accessor functoid allows access to the file adapter properties within an orchestration. So, what normally would be unavailable within a map is now made available. I was able to add a node to our target schema, and map ReceivedFileName to it. Here’s what it looks like:

Screen Shot 2013-02-20 at 11.05.35 AM

Here’s how to do it:

  1. Grab the .dll from codeplex [[link]]
  2. Save the .dll to \Microsoft BizTalk Server 2006\Developer Tools\Mapper Extensions (Thanks rajwebjunky!)
    • If you do not have BTS 2006 installed, save the .dll to \Microsoft BizTalk Server 2010\Developer Tools\Mapper Extensions
  3. GAC your assembly
  4. Add the functoids to your functoid ToolBox
    • Toolbox>Right Click>Choose Items…>BizTalk Mapper Functoids
  5. Drag and drop the functoid into your map! (I needed the Orchestration Context Accessor, but you can also use the Receive Port Context Accessor functoid to access properties in receive ports)

Note: Be careful when using this in Dev. If you GAC your assembly on your dev box, you will also need to do the same in your test/prod box. To be safe, I created a new MSI for our solution, and deployed that instead of updated dlls to BizTalk.

Special thanks to Eliasen for having such a great post for me to start from!

UPDATE: See this Improved Context Accessor post for more functoinality.

Convert Strings to Numbers in a Functoid

Convert Strings to Numbers in a Functoid

As shown in my previous posts, I have been tackling some messy maps in Visual Studio for our BizTalk solution. I inherited some confusing and broken source code, and am just now getting it all to work!

One of the issues I was having was mapping both the begin dates and the end dates of a record, by using the cumulative minimum or the cumulative maximum of dates. The source system sends dates as a string, in the YYYYMMDD format. When I tried to take the cumulative max or min, I would consistently get no data. I could map without the cumulative functoids, but that does not follow our business rules.

Question: What was causing my cumulative max/min functoids to blow up?

Cause: Cumulative maximum and cumulative minimum functoids only consistently work with numeric values, and not strings. See:

Solution: Custom string-to-numeric scripting functoid.


Here’s how it works. The scripting functoid gets the date from the source xml, converts it to a number, and then the cumulative max/min functoid works like a charm. Once the date is parsed via the string extract functoids, and reformatted in the string concatenate functoid, it is back in its string format. Here is the code in my scripting functoid:

public Int32 ConvertDatetoInt(string param1)
                return System.Convert.ToInt32(param1);

Pretty simple, quite nifty.

Creating Complicated Maps in Visual Studio

Perhaps you have a rather large task of creating a complicated map with countless functioids. Or, like me, you are inheriting horrifyingly messy maps from another person. On my first ever BizTalk deployment project, I inherited this:

One page, 150+ nodes, countless functoids. Now let’s make this point clear: this is my first ever BizTalk project. Other than doing MSDN’s EAI and EDI tutorials, a few articles, and hours in a conference room doing knowledge transfer with a coworker, my knowledge is limited to my google search proficiency.

The developer before me left our company about a month ago, without much to hand off besides broken code and missing documentation. As many of you know, this is actually not very uncommon. Because of this, let’s discuss a few ways you can make your (and your replacement’s) life much more stress-free:

1: Document Everything

This should be a given. No matter how smart you are, you will make mistakes. So why take the chance? Break out Excel, go through each element, know your source system, know your destination system, and document what needs to happen in-between.

2: Use your Documentation

If you document your mappings appropriately, you will have two major advantages. You will have a consistent playbook to reference throughout your development, and you will have a binding document to assure data consistency from the source and destination systems. The latter advantage is the one most don’t think about; however, when you get accusations about incorrect data during testing, you can reference your document, and be on your way.

3: Map on Multiple Pages

See how on the bottom of the window in Visual Studio, where it says “Page 1, Page 2…”? That means you can use multiple pages for a single map. This probably sounds patronizing, but I have already seen quite a few prod maps with a large headache on one single page. Below is an image of the same map, but with one tree split out to another page.


4: Label your Functoids

Okay, at this point, you may think I am being a bit too anal. Who actually takes the time to label their functoids, anyway? To be honest, I am probably one of the most impatient developers you will meet. Documentation is painful, and writing pretty code was a forced adaptation of mine. So labeling functoids is just one extra step that can seem too meticulous. However, it is a lifesaver. When you look at a map in Visual Studio, you cannot see every bit of logic. You are missing the order of operations and the specific operations taking place.

For example, the String Concatenate Functoid:


From this menu, can you tell what is taking place? When multiple functoids lead into a string concatenate functoid, there is absolutely no way to know which input is Input[0], Input[1], or Input[2]. However, if you label the functoids leading into the String Concatenate Functoid, you can see exactly what operations are taking place.


This very situation saved my rear when dealing with date formatting, and I have labeled my functoids ever since.

5: Don’t Rush

There is always stress to get a project done faster, but remember: a bit more time spent up front can save hours of frustration in the future. We all know that debugging is not the easiest thing to do in BizTalk, so let’s minimize those occurrences.

So grab some headphones, put on your favorite tunes, and spend some time with these maps. Use your documentation, think through the logic, and have fun!

Generate XSLT from BizTalk Map

Generate XSLT from BizTalk Map

Some programmers are much more comfortable reading XSLT over looking through the confusing webs of BizTalk maps. I found this article very helpful in helping generate to that XSLT in Visual Studio.

Open the Map in Visual Studio > Right click on the map to convert > Click on “Validate Map” > Control-click on the file location in the Output window.

After you validate a map, the XSLT should be available in your local app data. You can find the files at C:\Users\[username]\AppData\Local\Temp\_MapData

Quick, easy solution.

Maps can get messy