BizTalk Error: Failed to grant permission to execute. (Exception from HRESULT: 0x80131418)

Here is an issue I ran into for BizTalk 2009 when using the WCF-BasicHttp or WCF-WSHttp adapter. 
I received the following error:
The adapter "WCF-WSHttp" raised an error message. Details "System.Security.Policy.PolicyException: Failed to grant permission to execute.
What was I doing?
What I was trying to do is expose a schema as a web service endpoint so that any calls to that service would dump that message straight to the message box.  Now … not wanting to expose my internal schema I created a schema definition especially for this service and a corresponding map to map it to my canonical/internal schema.  Deployed the solution.
Next, I used the handy BizTalk WCF Service Publishing Wizard to create the .svc and ports, etc.  I then updated the Receive Port to run the map.  When I tested the endpoint I got the above error.  I then removed the map and the test ran succesfully (albeit with my intended map). 
What the heck was happening?
Well … as luck would have it I had quickly ramped up this virtual server environment and put the portal on port 80 which meant WSS was running on port 80.  Upon inspecting the .NET Trust Level for my web application it was set to WSS_Minimal!!! Arggg!  I had spent way too much time on this one!
What was the fix?
Just some things to remember when setting up a web application to run a service into BizTalk:
  • Create a separate App Pool running as a user that has permission to the BizTalk Isolated Host (I just ran it as my BizTalk Iso service account as a shortcut)
  • Make sure this app pool is running as classic mode and not integrated mode
  • CHECK THE TRUST LEVEL to make sure it is appropriate … in my case I just set it to Full Trust to get it through my test
  • Don’t for get to enable the receive location, it is not enabled by the wizard … you couldn’t imagine how many times I forgot to do this while trying to figure out why my darn service isn’t working again!

Well … hope this helps someone else!


Checking in BizTalk file before editing can corrupt the file

We’ve all been there…
When you are working with a team of developers (whether two or ten),
who are collaborating on a project in Visual Studio.Net, there
certainly is the chance that you will need to add a new file to the
solution.  Of course, to do this you have to check out the project
file locking it for yourself.

Play Nice!
The courteous thing to do (karma, right?) is to add your file and
immediately check in the new project file with your newly added file
(as long as it doesn’t break the build 🙂 ).  Try doing this in
BizTalk sometime (if you already haven’t) and watch the quick
destruction of your file.  Once you start editing that file again
and check it back in you get a nice little warning about the encoding
type changing.  Visual Source Safe does not handle this very
gracefully; Visual Source Safe does not handle this at all.  You
will be fooled into thinking your file is safe because you are working
with the version on your local disk but the next time one of your team
members gets the latest version of your project the file will be toast.

What the …?
The issue here is that when you create new files in it likes to
create them as UTF-8 encoded files.  Seems like a good idea; a
nice standard encoding type.  BizTalk, however, has to be
different and save everything as UTF-16.  Once again, another
nice, standard format.  However, visual source safe is completely
oblivious to the change in encoding types an will gladly assume that
your are still managing a UTF-8 encoded file.

The Moral
You can still be a gracious team member and have a quick
turn-around on adding new files to the project but just give those
files a little edit first before you check everything in.

True != true … duh!

Ok … so once again one of the simplest of errors put me into out-thinking-myself mode.  Simply put, when you have a boolean in an XML file that goes into a BizTalk Orchestration, it is case-sensitve.
So if you get an error stating that you have invalid text for your System.Boolean type then now you know: "True" is not true … "true" is true.
Put this on under the "duh" category.

Problem naming a BizTalk operation ReceiveMessage or SendMessage

Here was a strange one that took me a while to nail down.  First, the error messages:
The keyword new is required on ‘Microsoft.Samples.BizTalk.SendMail.ReceivePortType.ReceiveMessage’ because it hides inherited member ‘Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.ReceiveMessage(int, Microsoft.XLANGs.Core.Envelope, Microsoft.XLANGs.BaseTypes.XLANGMessage, Microsoft.XLANGs.Core.Correlation[], Microsoft.XLANGs.Core.Context, Microsoft.XLANGs.Core.Segment)’

‘Microsoft.Samples.BizTalk.SendMail.ReceiveSend.ReceivePort’ denotes a ‘field’ where a ‘class’ was expected

Static member ‘Microsoft.Samples.BizTalk.SendMail.ReceivePortType.ReceiveMessage’ cannot be accessed with an instance reference; qualify it with a type name instead
‘Microsoft.Samples.BizTalk.SendMail.ReceivePortType.ReceiveMessage’ denotes a ‘field’ where a ‘method’ was expected
After searching for a few hours on the Internet for that one and playing around with recent changes I had made I finally had realized what I did:  I was getting a little too creative for my own good (or not creative enough, perhaps). 
I decided that Operation_1 and Operation_2 were not good names for my receive and send ports so I decided to name them something else.  Of course, in a burst of creativness I used ‘ReceiveMessage’ and ‘SendMessage’ for the names.  I had done that a while back but apparently never did a build as I made several other changes since.  Then I compiled and got the errors above on the receive port.
Figuring it had something to do with the ports I decided to just nuke them and recreate them.  I used my usual internal justification that Microsoft’s software had somehow screwed up my code (uh … it never turns out that way).  After doing this everything compiled just fine once again.  Ah Ha! It was Microsoft screwing up my code! Then I immediately went and renamed the ports once again to my ever-so-creative names and boom. 
Moral: Either get very creative with your naming or have a complete lack of creativness altogether.  Don’t sit in the middle.