BTSR2: How to turn a BizTalk WCF Published Service into a MEX point as well

by | Jun 24, 2007 | BizTalk Community Blogs via Syndication

Sometimes when you have a published WCF Service, you may just want to allow that service
to provide a description about itself – rather than go through yet another wizard
(re-run the WCF Publishing wizard) to expose out some metadata.

I’ve been doing alot of R2 lately and this exact problem came up. Fortunately I found
a quick and easy way.

Simply add the following lines to your Web.Config before the </Configuration>
tag
(take it out when you’re finished)

 

<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name=”ServiceBehaviorConfiguration”>
<serviceDebug httpHelpPageEnabled=”true” httpsHelpPageEnabled=”false” includeExceptionDetailInFaults=”false”
/>
<serviceMetadata httpGetEnabled=”true” httpsGetEnabled=”false” />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<!– Note: the service name must match the configuration name for the service implementation.
–>
<service name=”Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance” behaviorConfiguration=”ServiceBehaviorConfiguration”>
<endpoint name=”HttpMexEndpoint” address=”mex” binding=”mexHttpBinding” bindingConfiguration=””
contract=”IMetadataExchange” />
<!–<endpoint name=”HttpsMexEndpoint” address=”mex” binding=”mexHttpsBinding”
bindingConfiguration=”” contract=”IMetadataExchange” />–>
</service>
</services>
</system.serviceModel>

 

It doesn’t get easier – enjoy!

Debugging into the .NET XmlSerializer

by | Jun 20, 2007 | BizTalk Community Blogs via Syndication

I’ve had several occasions now where someone with Sogeti or someone at a client has

had a “truly mysterious” problem where the XmlSerializer was throwing an error which

the programmer simply couldn’t understand. When situations like this arise,

I find myself reaching for a great

post written by Scott Hanselman on this issue which I will repeat the meat of

which here so that I’ve got a copy of my own.

If you find yourself needing to debug the code generated by the XmlSerializer to serialize

or deserialize your type, here is what you need to do:

1. Modify your app.config or web.config to include the following:


               1:

              <?

              xml

              version

              ="1.0"

              encoding

              ="utf-8" ?>

               2:

              <

              configuration

              >

            

               3:

              <

              system.diagnostics

              >

            

               4:

              <

              switches

              >

            

               5:

              <

              add

              name

              ="XmlSerialization.Compilation"

              value

              ="1"

              />

            

               6:

              </

              switches

              >

            

               7:

              </

              system.diagnostics

              >

            

               8:

              </

              configuration

              >

2. Recompile your application and set a break point just after you create your XmlSerializer.

3. Open the directory “C:\Documents and Settings\[username]\Local Settings\Temp”

4. Find the .CS file with the most recent timestamp, it will have a random file name.

5. Open that file in the same Visual Studio you’ve got debugging, and set a break

point.

6. Debug to your hearts content.

Important to remember at this point is that this code is generated by the system and

is meant to be fast, not friendly. You’ll need to be very familiar with the

XmlReader object or you won’t understand how it is doing what it is doing. Also

realize that you can’t control that code, you can only control the attributes on the

Type you gave it, and from that it will generate the code as it sees fit.

Side Note : One of the classic performance mistakes I see people

make when they start doing a lot of XML serialization is to create the XmlSerializer

object every time they need one. The constructor of the XmlSerializer

is the most expensive part of it’s operations. It is there that the code is

generated which you are debugging above, and so once you’ve created an XmlSerializer

if you’ve got a reasonable expectation of needing it again then keep it around!

Well Well Well

by | Jun 20, 2007 | BizTalk Community Blogs via Syndication

First of all I want to apologise… SORRY!… to the 50+ people that attended last nights .Net user group in Auckland. I came down with a migraine less than an hour before I was due to present and Sean stepped in to deliver the session. Talking to Sean today he enjoyed the session and fielded some great questions. Sean said he will post his links shortly.


On another note I see Dr Sneath has done a great post demo’ing the power of Silverlight Video (who needs blink when you have skew 😉