The subst command

• Posted by Jeremy Bokobza on December 3, 2008
• 15 comments

Here is a quick one I always forget.

There is a possibility to map a folder to a virtual drive using the DOS command subst .

This is quite useful if there is a folder located quite deep in your file system that you use quite often and that you want to be able to open easily.

For my documents folder, I would type something like this:

In Run, type subst s: C:\Users\Jeremy\Documents and then press OK.

Now open Run again (or even any folder window) and type s:

The path you specified (here C:\Users\Jeremy\Documents) in the command is now substituted by s:

Note that when you assign a shortcut like this, the drive letter you chose will not be available in Map Network Drive anymore as it is already assigned.

This will last until you restart your computer or delete the drive with the command subst s: /D

GACing made easy.

• Posted by Jeremy Bokobza on August 28, 2008
• 16 comments

As a BizTalk developer, you need to GAC, GAC and GAC again, over and over.

Oh, GAC stands for Global Assembly Cache (but everyone that reads this article knows that, right?), and "to GAC" means to put an assembly in the GAC.

So as I said, this action of GACing is repeated many times during development and, let's be honest, it's a pain.

The reasons why GAC is good for you are multiple:

- it gives you the ability to use the same assembly for multiple applications (hence its name)

- you can have multiple versions of the same assembly deployed thus allowing side-by-side execution.

To GAC, someone that just starts using BizTalk usually clicks on the project, copies the path of the project folder, open Run, copy the path, go to the bin folder, open the GAC folder (Run --> assembly) and drag the compiled assembly to the GAC.

Copy-Paste does not work, an assembly is added/updated to the GAC only by dragging.

And you have to do that every time you want to run your application using the latest version of either a BizTalk assembly or an assembly BizTalk uses. 

And that's really annoying, don't you think/know?

There are ways to do it just painless, one click or two at most.

By the way, on a development machine it's not so important, but believe me when you need to apply a single patch to a production environment, it is essential you backup, just in case you made a mistake and need to rollback.

So first, let's see how you can backup the assembly stored in your GAC.

Type C:\WINDOWS\assembly\GAC_MSIL or C:\WINDOWS\assembly\gac (gac in lowercase) in Run and you have all the folders with your assemblies in them.

Backup and now you can GAC.

Now, as I said, there are a few ways to GAC an assembly much faster than described above.

There are 3 solutions I know of, it's up to you to use the one that suits you most.

• First you can add a registry entry that will allows you to right-click on the assembly and GAC it.

  To do this, you create a file called for example addToGAC.reg, edit it and copy the following:

  [HKEY_CLASSES_ROOT\dllfile\shell\Add to GAC\command]
  @="\" C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\Bin\\gacutil.exe\" /i \"%1\""

  Now if you right click the assembly, you'll see the "Add to GAC" option and this will add the assembly to the GAC.

You won't have to drag anymore, which is already two steps less, but you can do better.

Here's how:

• In VS, go to Tools -> External Tools, click on Add, and enter a

     - title, for example "GAC assembly"

     - command  : c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe

     - argument: /i $(TargetPath)

     - initial directory: $(TargetDir)

       and apply.

   

    

  When you build a project and you want to add the assembly to the GAC, just have the project highlighted, and click Tools --> GAC assembly and that's it, it's GACed. Of course you have to do this step once in your environment and that's it.

No more bin and development opened folders by the dozen.

Even better than the previous solution, right?

• Alternatively, you can also have a post-build event that will  automatically GAC the assembly after a build, but be cautious because sometimes you want to build but don't want to install to the GAC automatically so this option can get pretty annoying.

  If you're interested though here's how you do:

  • For a BizTalk assembly, just set to true the option "install to global assembly cache" in the BizTalk project properties.

    This will install the assembly to the GAC only after deployment, not build.

    Here you're better off with the previous option.

  • For a .NET assembly, go to properties of the project, go to Build Events and in the Post-build event command line, copy this:

    "$(DevEnvDir)..\..\SDK\v2.0\Bin\GacUtil.exe" /i "$(TargetPath)" /f

    When you build, the assembly will be GACed automatically.

That's all.

Well, happy easy GACing!

Shortcuts for the BizTalk orchestration Editor

• Posted by Jeremy Bokobza on July 26, 2008
• 39 comments

Something I've noticed while working on an orchestration:

To add a shape, you can either right-click on a Shape connector line or use the BizTalk Orchestration Toolbox.

It can be quite frustrating sometimes when you use the first way because the shapes are not in alphabetical order so you have to read them all in order to get what you want.

If you right click on the shape connector line, show the choice of shapes and press one of the key below, the corresponding shape will appear.

Not such a big deal, but still useful.

W: Throw Exception

E: Send

T: Start Orchestration

Y: Delay

U: Construct Message

I: Decide

O: Loop

P: Parallel

A: Terminate

S: Scope

D: Suspend

F: Transform

G: Group

L: Listen

X: Expression

C: Call Orchestration

V: Receive

M: Message Assignment

 R: Call Rules (works only in atomic scopes…)

 N: Compensate (provided you're in a compensation block)

Weird Error in orchestration

• Posted by Jeremy Bokobza on July 26, 2008
• 13 comments

Sometimes, even though the orchestration does not show any error , when you build your project, you get a lot of them and when double-clicking the error it shows you something perfectly normal.

You can close VS ten times but it doesn't help…

This thing drove me crazy for a while until I knew what to do.

What do you do then?

Well, you know the orchestration is formed of 2 parts, right?

One is XML of type <om:MetaModel  xmlns:om="http://schemas.microsoft.com/BizTalk/2003/DesignerData"/> and the other is in X# (or Xlang if you want).

If you look at the Xlang part, you'll see that your error is showing there instead of the relevant piece of code.  However, in the XML, the code appears and not the error.

The conclusion is that it's the XML part that builds the Xlang part and not the opposite.

Great! Now what?

Edit the orchestration, get rid of the second one (basically everything below the #endif // __DESIGNER_DATA line), when rebuilding the project, it will behave as normal - showing no errors (provided that you really don't have any error there).

Now if after building you open your orchestration with the XMLEditor (right click -> open with -> XMLEditor), you'll see that the Xlang part has not been generated...

The thing is that the X# won't be generated unless you change something in the orchestration.

Just open any shape like an expression shape and add a random space anywhere and that will do the trick.

Edit again and you'll see the X#.