Calling an External Assemby from a Scripting Functoid

Having completed the official Microsoft course on developing with BizTalk (credit to QA-IQ for adding some great additional content to the course), I have been working on some projects in anger.

The most recent issue I had was around testing a map which used a scripting functoid to call my data layer to get some data out of a database.

I built a class library project which provides various methods to retrieve the data I need using the data layer. However when I referenced the project in my maps project (note that I keep all BizTalk file types e.g. schemas, orchestrations, maps etc in their own project for ease of deployment) I got an error essentially saying that the assembly could not be loaded. After some rooting around I found the problems.

The following is my checklist for things to look for if you are having problems with this:

• Make sure that all functions used on your assembly are working correctly first. Its much easier to know that you can rule out problems with your referenced code prior to using it in BizTalk.
  
  
• DO NOT set-up shared (static in C#) functions on your referenced assembly if you want to call them from a scripting functoid. BizTalk will natively try to instantiate your class so these will not work.
  
  
• Restart VS to ensure that all references have been freshly loaded.
  
  
• Ensure that the dll for your referenced project is installed in the GAC on your development machine.
  
  
• If you are using the 'Test Map' functionality from within VS then you will also need to ensure that any config settings that are required for your assembly (e.g AppSettings) are included in the devenv.exe.config file. At runtime these settings will need to be put into btsntsvc.config on your live configuration.
  
  
• If you have updated your assembly then ensure that VS is trying to use the correct version, remove all references to your assembly and add them again.
  
  
• Refresh the GAC.
  
  
• If you wish to debug your referenced assembly then you will have to setup a test project to do this, however ensure that you un-install your dll from the GAC if you have already installed it as VS will try to use the GAC version first and this will not have a debug file associated with it. You will get an error saying that no debug information has been generated if VS is using the reference from the GAC.
  

I hope that this has been helpful. I suspect I will be adding a few more BizTalk related posts as I get to grips with some of the finer points of the technology.

VS2005 Unable to Complete Operation

This irritating dialog box when trying to debug a project in Visual Studio 2005 is one of those things that you just get used to. When it reared its ugly head this morning I realised that perhaps there were folks out there who were stumped by this.

I am not sure of the reasons for this but in order to debug your application VS creates two files in the bin > debug folder for your project. These will both end with vshost.exe and vshost.exe.config and will be prefixed by your project name. For some reason sometimes these files become corrupt and the VS gives the helpful dialog message above if you attempt to debug.

You need to shut down VS2005 and manually delete these 2 files. They will be recreated as soon as you try to debug again. You have to shut down VS2005 as it retains a file lock on these from when you tried to debug and so you will not be able to delete them unless you shut down the application.

Hope this helps someone out there trying to demystify this ridiculous dialog.

Ideal Hardware for Running Visual Studio

Are you looking for the ideal hardware specification for running on a development machine? I have to be honest that this is really down to the kind of development you are planning on doing with it, but Scott Guthrie over at Microsoft has posted an interesting article on his blog.

I would always have said that the key to a better development box is processor, processor, processor. However Scott proposes a spec which is more reliant on a speedy hard drive. Interested then check out the blog post and see what you think.

He makes a compelling point but its probably one that you need to try out. He also links to some further resources on developer specification hardware which are worth a look.

Deploying VSTO 2005 Customisations in an Enterprise Environment

A colleague of mine asked me last week to take a look at some deployment issues with VSTO 2005 customizations. I did do some searching and there is lots of information out there for all kinds of scenarios but there is some misleading stuff too. I thought it may be worthwhile to post some details about the method I used to get this working.

Note: There are many different deployment scenarios that you may come across but this is the way that I dealt with it.

• Firstly I built a VSTO 2005 customization. This was a simple document action pane which connected to a database and retrieved some details which were used to replace some bookmarks in a word document. However for ease you could just use the following code within the ThisDocument class.
  

  
  Public Class ThisDocument
  
      Private Sub ThisDocument_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup
    
          MessageBox.Show("This customization has been deployed!", "Success")
  
      End Sub
  
      Private Sub ThisDocument_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown
  
      End Sub
  
  End Class
  
  

• Once you have built something which works you will need to deploy it. The main consideration in our environment was that the code had to be separate to the document itself, this means that deploying updates is much easier as you only have to redistribute (to the client machines) the document and not the manifests or the compiled code.



• I established a network share with read access to the Everyone group and Full Control to a specific admin group for this type of work.



• In Visual Studio 2005, click on Build > Publish <ProjectName>



• At this point you must select the UNC address to your network share, if you don't use the UNC address then the permissions will be taken from the folder itself not the share.



• This will deploy the office document and all associated files to the specified share.



• At this point you could deploy the office document to all your client machines. However if anyone tries to run it they will get a .Net security error. This is because by default remote code execution is NOT allowed in the .Net Framework Configuration.



• You will need to use the caspol.exe command line application which sits in the c:\<winfolder>\Micrsoft.Net\Framework\<versionnumber>\ folder



• I used the following to set FullTrust permissions on my network share:
  
  caspol.exe -machine -addgroup LocalIntranet_Zone -url <yourUNCaddress>\* FullTrust -name "VSTOCustomizations" -description "Code group granting full trust to the code required for VSTO2005 extensions to Office"
  
  
• This should allow your VSTO code to execute from within the local office document.

I hope you find this useful. I have written it rather fast so I may revisit this if it gets a lot of negative comments. I would have found this really useful a couple of days ago.

Error: The breakpoint will not currently be hit. No symbols have been loaded for this document

Came across this little problem today whilst trying to make some amendments to an old project. My first thought was that the projects compile configuration was set to release so the .pdb file (this contains the 'symbols' reffered to in the error message) was not being generated in the 'bin' folder of the project.

After several minutes of searching on Google I found some forum posts over at asp.net/forums and on MSDN which related but the solutions posted did not seem to make sense to me.

Word of Warning - If you are new to .Net development then please do not trust the first solution that you find. A lot of posts on forums etc. contain long winded or misleading solutions. Get a consensus from a couple of sources before attempting to fix the problem.

I sat and thought for several minutes and the best solution to my mind was to first ensure that all reference to the project output were set to Debug.

If you are having this problem then please check the following:

• Project Properties > Compile > Advanced Compile Options > Generate Debug Info is set to either Full or pdb-only
• Project Properties > Compile > Configuration set to Debug or Active (Debug)
• Build > Configuration Manager > Active Solution Configuration set to Debug, and debug is set for all projects displayed here.

After making the above checks then try REBUILDING your project. The pdb file should have now been regenerated. If not then close VS2005 delete all .pdb files for the project (from the bin folder). If you open your solution and try to rebuild again these pdb files should be rebuilt in the bin directory allowing you to debug normally.