On the whole - BTSTask.exe is a great improvement over BTSDeploy.exe in 2004.
A couple of things I wouldnt mind seeing in this tool - the ability to start/stop deployed applications.

Big Gotcha
Something I came across after my large scripting effort.....it goes something like this....
(1) 3 biztalk applications - a 'Core' and Two others.
(2) For the 'Core' apart from Schemas, Maps, Pipelines + Orchestrations; I had 1 COM Assembly, 2 custom adapters, 4 custom functoids and 3 custom pipeline components

So a reasonable sized deployment that needed to easily be deployed into test/production.

My line of thinking was - "If I could get all the associated *.dlls deployed into the BTS Core Application wthin Development...all would be good."
So as we know we can go through the BTS Admin Console and add resources/files/bindings etc. to our application (with various options), that way when we say "Export to MSI..." it's self contained.

The PROBLEM is in the 'Destination Location'....
Using the BTSTask AddResource..... setting the '-Destination:' parameter works a treat (IF your destination location exists within development environment!)

Let me ellaborate....
Development:
e:\projects\<project name>\BizTalk\
     - maps
     - schemas etc....
Associated *.dlls - found e:\projects\<project name>\CommonBin\Release

Testing/Production:
d:\Applications\<project name>\CommonBin...etc. etc.

So the drives are different and what's more, there is NO d-drive in Development....hmmm....I thought.

(I didnt have a 'demo' project to highlight this....so I've removed company info from below)

Where I want to focus is the 'Destination Location'

These 4 assemblies are deployed using VS.NET 2005 straight from the developers desktop.
(When using BTSTask AddResource....-Destination:<loc>   - loc has to exist at time of adding and 'exporting MSI' - bts validates)

Export to MSI...fine MSI finally created.

Installing the MSI file in Production/Testing
Upon performing MSIEXEC /quiet /i Core.MSI FOLDER=d:\Applications\<Project Name>\CommonBin\
I ended up getting a 'msi package deployment' - a guid as a foldername with *.CAB files underneath. No *.dlls etc to be seen.

Importing Into BizTalk
Went to BTS Admin Console and did ImportApp - all looked good.

Then went to the D-Drive and found no new files?? where were my biztalk files? gac-ed files etc?

The ones that needed Gac-ing - found copied to the GAC
The BizTalk ones Schemas, Maps etc - found in E:\projects\<project name>\<development project path>\Bin\Deployment\.....smooth! :-(

As far as I can tell this is attributed to the already existing 'destination location' within the MSI on the BizTalk artifacts.

So the reason why it's soooooo close is that if we could override this (i.e. the above FOLDER= parameter takes effect) then all would be sweet in going from environment to environment.

As it stands at the moment, I'm deploying all the files to Testing building the MSIs there and then deploying to Production with all the correct paths hopefully.

Thought I'd save you some tears.

Buried deep down in one of the Install Guides (multiserver, pg 23) I came across a section that shows you where to change the BAM alert email formats.

Basically there are two files - emailNotification.xslt and fileNotification.xslt both found in the ...\Microsoft BizTalk Server 2006\Tracking directory.

If you want to split the function of BAM alerting to different machines (the Provider, Generator and Distributor within the Notification Services) then there's a little step you need to do, to tell the BAM Alerting Event Provider where these new XSLT files are.

Within the Tracking Dir:

1. Run ProcessBAMNsFiles.vbs - this creates a *.adf file.
2. Edit the *.adf file to point to the new names/location of your modified *.xslt files.
3. ReRun ProcessBAMNsFiles.vbs so it picks up the modified *.adf file and makes the changes to the BizTalk Runtime.
4. Restart the BAMAlerts Windows Service.

Handy one - especially being able to modify those emails.

From students one of my most asked questions about MOSS is...."Will it handle an upgrade?"...something along the lines of .."...you know we have a medium installation of 183 distributed V2 sites with central portals, index propagation and search."

So I thought I'd outline some of my initial upgrade experiences from MOSS RTM.
(On this install - used by a small-medium sized company, they were up for technology so we had SPS2003+SP2...->MOSS Beta2 installed for a while. The RTM install wouldnt kick off until I removed Beta2)

After the product key in the setup I got these upgrade screens....(once the product is installed we can always run the psconfig.exe to start the 'wizard')

I'm doing all at once here - as this company is pretty standard in that fashion. Customisation here weigh in at about 10% of the overall Sharepoint site functionality.

Here's the screen for the File Locations - I moved these out to D-Drive (separate disk) and all the Indexing will be hit pretty hard.
Rule of thumb is to allow 200% space increase for the indexed content. So if you're indexing 100MB, then 200MB free for indexing is recommended.
Actually the search/index process in MOSS is pretty well defined and taking its roots from 'Indexing Service' many many moons ago. The indexes (known as Catalogs - you can access these through the APIs etc) are stored in a highly optimised format. Compressed! And the process of 'indexing' content can be 'tweaked' through things like 'the number of Word lists' in memory, Shadow Indexing and finally the master Index.

Some one was smiling....:)

So at this point I have all the binaries installed and all the appropriate files registered.
The Wizard will go and (hopefully) create the first Admin Site, which from there I can provision the actual Content based sites and the Shared Services (search, excel, mysite etc)

(damn...got hit with a 'we need to reboot to continue...' - so rebooting now.)

Just came across this great info I thought I'd share with you all.

If you're like me over Christmas you'd be giving some thought on how to make the most out of your newly slated WSS/MOSS 2007 Server.

Hold onto your hats - stop all custom development and give your graphic designers a buzz.......

Here's something to keep an eye on in the coming weeks!! Over 40 new templates......

http://www.microsoft.com/technet/windowsserver/sharepoint/wssapps/v3templates.mspx

Here's a snippet from the page.....(expense site, bug tracking....:)

Coming Soon: New Application Templates for Windows SharePoint Services 3.0

Application Templates are out-of-box custom scenarios for the Windows SharePoint Services platform, tailored to address the needs and requirements of specific business processes or sets of tasks in organizations of any size. Microsoft will release a new set of 40 application templates for Windows SharePoint Services 3.0. Some of the previous scenarios, such as Help Desk, Project Site, Knowledge Base and the Employee/HR templates will be improved to incorporate and highlight new capabilities in Windows SharePoint Services 3.0. New scenarios will also be added to address specific customer needs and business requirements. While Application Templates can be used to solve particular business needs, they can also provide a starting point for partners and developers looking to build deeper Windows SharePoint Services solutions. The new templates will make use of Windows SharePoint Services 3.0 capabilities and be compatible with Office SharePoint Designer 2007 to help make customization easier.

Multi-Language Server Admin Templates Absence Request and Vacation Schedule Management Budgeting and Tracking Multiple Projects Bug Database Call Center Change Request Management Compliance Process Support Site Contacts Management Document Library and Review Event Planning Expense Reimbursement and Approval Site Help Desk Inventory Tracking IT Team Workspace Job Requisition and Interview Management Knowledge Base Lending Library Physical Asset Tracking and Management Project Tracking Workspace Room and Equipment Reservations Sales Lead Pipeline

English Only Site Admin Templates Board of Directors Classroom Management Clinical Trial Initiation and Management Competitive Differentiation Site Discussion Database Emergency Management for Government Agencies Employee Activities Site Employee Self-Service Benefits Employee Training Scheduling and Materials Equity Research Manufacturing Process Management Marketing Campaign Planning and Execution New Product Development New Store Opening Product Portfolio and Profitability Management Request for Proposal Sports League Team Work Site Timecard Management Vendor Performance Rating

(This is courtesy of Ross a collegue of where I'm working onsite currently)

What you need is:

(1) a Send Port with the MSMQ Send Adapter
(2) XMLTransmit pipeline

Within the MSMQ Send Port adapter - set the Body Type to a value of 30 (this translates back to the Win32 API values and you can look them up for the enumeration, so it's not a value of 8=BSTR a trap which we may fall into)

Within the XMLTransmit pipeline - click on the ellipse to set per instance configuration settings for this pipeline.

Set 'Include XML Declaration' =false

Set 'Preserve BOM...' = false (byte order mark - the 3 chars that are a bomb, upside-down question mark etc) so the client wont receive it.

Once this is done - all good!

Your clients who expect just ActiveX formatted messages only, are happy to play with BizTalk.

Thanks Ross!

From an earlier email today.....

MS Partners Save 25-30% on Certification Exams

December 5, 2006

In concert with Microsoft’s Partner Skills Plus program, Microsoft Certified Partners, Gold Certified Partners, and Registered Members can save 25-30% on Microsoft certification exams – currently available only at Pearson VUE® Authorized Test Centers. These certifications are focused on the latest Microsoft products and technologies and align to Microsoft Partner Program competencies. Significant savings are also available on practice tests from MeasureUp. This is a limited time offer; visit https://partner.microsoft.com/examsavings to request your vouchers now.

Not currently a Microsoft Partner Program Member? Becoming a member of the Microsoft Partner Program can open new windows of opportunity for you and your organization. To enroll in the program or to associate your email address with a partner company, visit https://partner.microsoft.com/examsavings and click on ?Program Membership.? There is no cost to enroll as a Registered Member; join now and start saving on exams today.

Lots of cool things about R2 in the pipeline and one of them is BizTalk's deep integration with WCF.

What does that mean for you? If you havent already, start looking at WCF as going forward I believe that the majority of BizTalk solutions will be incorporating WCF in a big way.

I'm currently writing a course for R2/WCF/WF stuff and I thought I'd jot down a table so WCF things stick in my mind.

WCF Endpoint = Address + Contract + Binding
WCF Binding = Transport + Message Encoding
WCF Contract = Message/Data details
WCF Address = <moniker>://<server>:<Port>/<endpoint URI>

Binding Types

• BasicHTTPBinding - Maximum interoprability through conformity to the WS-Basic Profile 1.1
• WSHttpBinding - HTTP communication in conformity to the WS-* procotcols.
• WSDualHttpBinding - Duplex HTTP communication, by which the receiver of an initial message will not reply directly to the initial sender, but may transmit any number of responses via HTTP in conformity to WS-* protocols.
• WSFederationBinding - HTTP communication, in which access to the resources of a service can be controlled based on credentials issued by an explicitly-identified credential provider.
• NetTCPBinding - Secure, reliable, high-performance communication between WCF software components across the network.
• NetNamedPipeBinding - Secure, reliable, high-performance communication between WCF s/w components on the same machine.
• NetMSMQBinding - WCF communicating over MSMQ
• MsmqIntegrationBinding - WCF entities communicating via MSMQ
• NetPeerTcpBinding - WCF entities communicating via Windows Peer-To-Peer services

(ones that are missing at the moment - 'Interprocess Communication Binding' IPC, was in the early betas.....and SQL Server Service Broker)

Handy one to keep around

setup.exe /s config.xml /l <logfile> /CABPATH <cabfile>

That will help the clusters.

David McGhee and I were tasked with giving a RFID session at the recent Microsoft SOA Conference here in Sydney.

How hard can it be I thought?.....David got it all under control......me....I'll stick my hand up for the 'demo dolly' and give a 15-20min demo (or that's what I thought)

Enter the world of RFID readers (it can write to the tags as well...so dont be mislead by the 'reader')

We needed tags! So the UMD folks in Melbourne responded fantastically given the phone call in the afternoon, we had tags in our hot little hands the following morning - well done guys!!!

Armed with my trusty Intermec RFID mobile Reader (IP4) and 30MB worth of install files for their SDK - I thought I'm armed and dangerous.

"What to give a demo on?"

David & I chatted about this and came up with:

(a) delegate registers at 9am on the day (we were still 'writing' peoples IDs at 8.45am that morning - talk about cutting it fine  )

(b) when they walk into sessions/halls etc.up on the screen flashes their name somehow and says 'welcome'

(c) for a 'lucky' door prize - as the person walks past the reader for the session, it randomly writes back to the tag to indicate they were a winner (this is the optional extension - just in case I couldnt sleep)

So David decided to built the 'welcome' up on the screen component.

Were are both a big fan of MSMQ so......a simple queue with the persons details in the message was cool for David to flash up on the screen. I always believe a picture tells 1000 words and people arent really going to be too interested in what happens at the back end.....colours, lights action is where it's at.

David joined me in the sleep deprivation stakes (we both have little ones at home...reality hits home).

We had a dodgy 'ad-hoc' wireless network coming off my laptop, RFID Services running as a virtual image on my laptop, a mobile RFID PPC reader that wanted to connect to any wireless network going and David's MS Corp policy locked down Vista laptop - saying "here's a public workgroup mode MSMQ......sure you can send to it )

What a receipe!!! Did we pull it off......oh yeah!

David's application:

(a) was written in XAML, WPF

(b) Said 'Welcome' in not just English, but 32 different languages - EVEN Japanese! Little squiggle characters etc. (I just took his word for it that it said 'Welcome')

(c) looked great!

(d) had a whole stack of animations and bubble paths that floated showing each persons details for 6 seconds. Max of 4 bubbles on the screen at any one time.

(e) listened to a local private MSMQ.

Micks application:

(a) wrote a PPC application that did nearly all the functions (took 1 week) with the RFID reader - using the Intermec BRI apis.

(b) plugged the Intermec IP4 reader into Microsoft RFID Services (Sept CTP) and grabbed the provider from Rob (Intermec US based developer - sensational help from those guys) - did what I did in (a) in around 30 mins.

(c) Wrote a 'process event handler' to process each of the tags coming through and obtain the corresponding delegate details. Finally wrote to MSMQ ready for the UI. (I want to move some of this into the BizTalk Rules Engine that ships with RFID services)

Issues:

The bits I was using were all pretty rough and ready - the provider, rfid services etc. Quite frequently things would have some pretty major exceptions - due to what I was trying to do, through to not all the expected data being present during a tag read.

Whenever an Exception occured it usually meant that the reader needed to be 'warm booted'

Fantastic relationship

There are so many ways to setup RFID Services with readers, from the readers being pretty 'dumb' to have a serious amount of intelligence on the reader and RFID services just goes off what the reader 'says'.

I decided to go for the latter and here's why

(1) When we read tags on mass, this is usually done via Async RFID Reads (from the perspective of RFID Services). During this mode, our Reader was constantly checking if a tag was in the area, so no write back to the tag was possible as the reader was saying 'I'm reading, go away'.

(2) We could set this reader up to Poll - every 5secs or so, shoot out a pulse and say "who's there?" - problem this was still an Async read.

(3) Rob helped out greatly here - when I decided to let my Pocket PC App do the 'reading' and send back 'READ Tag notifications' to RFID Services. This allowed me to during the event processing (c.f. a biztalk pipeline) - open up a connection back to the reader (through Intermec APIs) and tell the Reader to Write a tag! (I actually didnt get this part done, but we're close)

All in all - what an experience. Learnt alot in the area of hardware, jiggles, and tweaking cables to get things 'just right'

And I've got to say I've had some wonderful help from Anush (MS RFID Services Product manager), Matt and Rob (from Intermec) - really refreshing to get such good and responsive help.

Thanks all!

Grab the Slide Deck - The_ecoSystem_for_RFID_in_BizTalk.zip (3.23 MB)
Grab the RFID Applications - RFID Apps.zip (634.05 KB)

Came across this handy page during my searching travels.
Covers the common Context Properties and gives a little blurb on each.

This is taken from MSDN

System properties are mostly used internally by BizTalk Messaging Engine and its components. In general, changing the values set by the engine for those properties is not recommended, because it may affect the execution logic of the engine. However, there are a large number of properties that you can change.

The following table contains a list of message context properties that the Messaging Engine can promote. You can use these properties for creation of filter expressions on send ports and orchestrations in Microsoft® BizTalk Server 2006. A separate table lists additional properties that may be of use in some BizTalk applications that cannot be promoted.

For additional information about properties and property schemas associated with pipeline components and adapters, see the following:

• BizTalk Message Queuing Adapter Property Schema and Properties
  
• File Adapter Property Schema and Properties
  
• FTP Adapter Property Schema and Properties
  
• HTTP Adapter Property Schema and Properties
  
• MSMQ Adapter Property Schema and Properties
  
• SMTP Adapter Property Schema and Properties
  
• SOAP Adapter Property Schema and Properties
  
• BizTalk Framework Schema and Properties
  
• MQSeries Adapter Properties
  
• POP3 Adapter Property Schema and Properties
  
• Windows SharePoint Services Adapter Properties Reference
  
• MIME/SMIME Property Schema and Properties
  
• XML and Flat File Property Schema and Properties
  

Property	When and where it is promoted	Type	Description
BTS.AckFailureCategory	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:int	Identifies the ErrorCategory, which gives the place and reason for the suspension.
BTS.AckFailureCode	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Identifies the ErrorCode, which gives the place and reason for the suspension.
BTS.AckID	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Identifies the MessageID of the original message.
BTS.AckInboundTransportLocation	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Identifies the InboundTransportLocation from the original message.
BTS.AckOutboundTransportLocation	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Identifies the OutboundTransportLocation from the original message.
BTS.AckOwnerID	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Identifies the instance ID from original message.
BTS.AckReceivePortID	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Identifies the ReceivePortID from the original message.
BTS.AckReceivePortName	Promoted by the Messaging Engine for the acknowledgement message.	xs:string	Identifies the ReceivePortName from the original message.
BTS.AckSendPortID	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Identifies the SendPortID from the original message.
BTS.AckSendPortName	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Identifies the SendPortName from the original message.
BTS.AckType	Promoted by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Allows monitoring of acknowledgements and non-acknowledgements by an orchestration. The value will be ACK for an acknowledgment and NACK for a negative acknowledgment.
BTS.ActionOnFailure	This property can be set by an adapter prior to calling IBTTTransportBatch::SubmitMessage() API to submit the message to BizTalk.	xs:int	Controls the behavior of the messaging engine when there is a failure in the receive pipeline. Typically the messaging engine suspends failed messages; however, certain adapters (like HTTP) would report the failure back to the client instead of suspending the message on a receive pipeline failure. Valid values: Default. If the property does not exist, the messaging engine will automatically try to suspend the message. 0. Indicates that the messaging engine should not automatically suspend the engine. Other values are reserved for future use.
BTS.CorrelationToken	If this property is set on the message context, it is promoted by the Messaging Engine. This property is set on a context implicitly when request-response adapter or an orchestration submits a request message into the MessageBox database.	xs:string	Enables routing of response to request-response ports.
BTS.EpmRRCorrelationToken	Promoted by the Messaging Engine on request-response message execution. The property is promoted before messages are submitted into the MessageBox database.	xs:int	Used internally by the Messaging Engine. Specifies the Server Name, Process ID and a unique GUID for a request response stream of messages.
BTS.InboundTransportLocation	Promoted by the Messaging Engine after receiving a message from a receive adapter and before publishing it into the MessageBox database.	xs:string	Specifies the location (URI) on which the message was received by the handler.
BTS.InboundTransportType	Promoted by the Messaging Engine after receiving a message from a receive adapter and before publishing it into the MessageBox database.	xs:string	Specifies the type of adapter that received this message and submitted it into the server: FILE, HTTP, etc.
BTS.InterchangeSequenceNumber	Pomoted by the Messaging Engine after receiving a message from the receive adapter and before publishing it into the MessageBox database.	xs:int	Indicates the sequence number of the document in the interchange. If the document is not part of an interchange that was disassembled into individual documents, then this value will be 1. The property can be read in an orchestration, a send pipeline and send adapter.
BTS.MessageDestination	This property can be set in the receive pipeline by a disassembler pipeline component when it returns a message from GetNext().	xs:string	Used primarily to support Recoverable Interchange Processing in disassemblers, this property controls whether a message is published to the message box or is suspended into the suspend queue. If a pipeline encounters a bad message in an interchange and wants to suspend the message and continue processing, it can do so by setting MessageDestination = SuspendQueue and return the message when the engine calls GetNext() on the disassembler. Valid values: Default. If the property does not exist, the message is assumed good and is published to the message box. SuspendQueue. Directs the messaging engine to suspend the message. Note The suspended message will be the post-pipeline/mapping message and not the message submitted by the adapter (i.e. the wire message).
BTS.MessageType	Promoted by the disassembler pipeline components during message parsing.	xs:string	Specifies the type of the message. The message type is defined as a concatenation of document schema namespace and document root node: http://MyNamespace#MyRoot.
BTS.OutboundTransportLocation	If this property is set on the message context, it is promoted by the Messaging Engine. This property is set on a message context implicitly when an orchestration sends a message to a send port. This property can be also set explicitly in an orchestration or in a pipeline.	xs:string	Specifies the destination location URI where the message is sent. The URI may contain the adapter prefix, such as http://. The adapter prefix is used by the Messaging Engine to determine the type of adapter to use when sending the message. If both the adapter prefix and the BTS.OutboundTransportType property are set, the adapter type from BTS.OutboundTransportType always takes precedence over the adapter type determined from the prefix. Valid values: BizTalk Message Queuing: DIRECT=, PRIVATE=, and PUBLIC= FILE: file:// FTP: FTP:// HTTP: http:// and https:// SMTP: mailto: SOAP: SOAP:// SQL: SQL://
BTS.OutboundTransportType	If this property is set on the message context, it is promoted by the Messaging Engine. This property is set on a context implicitly when an orchestration sends a message to a send port. This property can also be set explicitly in an orchestration or in a pipeline.	xs:string	Specifies the type of adapter used to send the message. The available adapter types are FILE, FTP, HTTP, SMTP, MSMQT (BizTalk Message Queuing), SOAP, and SQL. The values set on this property as well as adapter prefixes specified in the address are not case-sensitive.
BTS.PropertiesToUpdate	An adapter sets this property when it needs to preserve some of the property values on a failed message that is being resubmitted or suspended. This means that when the message gets resubmitted or resumed, it will have the specified properties set on the context.	xs:string	Contains an XML string with elements that represent property names, namespaces and values.
BTS.ReceivePortID	Promoted by the Messaging Engine after receiving a message from a receive adapter and before publishing it into the MessageBox database.	xs:int	Identifies the receive port on which the message was received.
BTS.ReceivePortName	Promoted by the Messaging Engine after receiving a message from a receive adapter and before publishing it into the MessageBox database.	xs:string	User-friendly name of the receive port on which the message was received.
BTS.RouteDirectToTP	Promoted by the Messaging Engine on messages for loop back or request-response execution. The property is promoted before messages are submitted into the MessageBox database.	xs:boolean	Used internally by the Messaging Engine to enable loop back and request-response scenarios.
BTS.SPGroupID	Promoted by the Messaging Engine when the message is sent to a send port from orchestration.	xs:string	Specifies the ID of the send port group.
BTS.SPID	Promoted by the Messaging Engine when a message is sent to a send port from orchestration.	xs:string	Specifies the ID of the send port.
BTS.SPTransportBackupID	Promoted by the Messaging Engine when a message is sent to a send port from an orchestration.	xs:string	Specifies the ID of the backup adapter in the send port.
BTS.SPTransportID	Promoted by the Messaging Engine when a message is sent to a send port from an orchestration.	xs:string	Specifies the ID of the primary adapter in the send port.
BTS.SuspendAsNonResumable	This property can be set by an adapter before calling SubmitMessage() or in an orchestration before sending a message to a send port. Note SubmitRequestMessage() will ignore this property; two-way messages are always suspended as non-resumable.	xs:boolean	Controls whether the Message Engine should suspend a message as non-resumable on message failure. Typically messages are suspended as resumable but there are cases when this is inappropriate -- for example, resuming a message for an ordered send or receive port would break message order. Valid values: False. Message is suspended as resumable (this is the default). True. Message is suspended as non-resumable.
BTS.SuspendMessageOnRoutingFailure	Promoted by the Messaging Engine after receiving a message from a receive adapter and before publishing it into the MessageBox database.	xs:boolean	Specifies behavior when a routing failure occurs with an incoming message. Valid values: Default / False. If the property does not exist or is set to False, the engine notifies the adapter of the error when a routing failure occurs. True. The routing engine will suspend the message automatically when a routing failure occurs. Note The suspended message will be the post-pipeline/mapping message and not the message submitted by the adapter (i.e. the wire message).

There are a number of other properties in this namespace that carry information that may be useful for some BizTalk applications.

Property	When and where it is promoted	Type	Description
BTS.AckDescription	Set by the Messaging Engine before publishing an acknowledgement message into the MessageBox database.	xs:string	Identifies the ErrorDescription, which gives the place and reason for the suspension.
BTS.EncryptionCert	Not promotable.	xs:int	Identifies the thumbprint corresponding to the encryption certificate. Set this property in an orchestration or custom pipeline component placed before the MIME/SMIME Encoder pipeline component in a pipeline to perform response encryption on a request-response port that is receiving a signed and encrypted message.
BTS.InterchangeID	Set by the Messaging Engine for each message that arrives on the server.	xs:string	Defines the unique ID that is used to group the documents that resulted from the same interchange message.
BTS.Loopback	Set by an adapter when submitting the request message for loop back execution.	xs:boolean	Defines whether the message should be submitted into the server for a loop back execution. In loop back execution, the request message is published into the MessageBox database where it is routed directly to the receive adapter as a response.
BTS.SignatureCertificate	Set by some adapters when submitting a message into the server. This property is used by the Party Resolution pipeline component.	xs:string	Identifies the thumbprint of the signing certificate that was used to sign the message received by BizTalk Server.
BTS.SourcePartyID	Set by the Party Resolution pipeline component after the party has been identified for the incoming message.	xs:string	The ID of the BizTalk party.
BTS.SSOTicket	If the receive adapter supports this property, it is set when publishing the message to a server.	xs:string	A ticket contains the encrypted domain and username of the current user, as well as the ticket expiration time. The ticket is used by SSO enabled adapters to get the credentials for the user when authenticating with destination endpoints.
BTS.WindowsUser	Set by some adapters when submitting a message into the server. This property is used by the Party Resolution pipeline component.

As you may know, the BTS VS.NET IDE plugin during a build goes off and compiles your BizTalk maps, schemas and orchestrations to C#.

Then from there we have another compile and viola - we have dlls produced.

The IDE uses the compiler XSharpP.exe to produce your C# files.

Wouldnt it be nice to see what the C# files are - also very useful for line by line debugging.

All you need to do is to create the appropriate Registry Key and corresponding value
Key Location: HKCU\Software\Microsoft\VisualStudio\8
Key Name: BizTalkProject
Value Type: DWORD
Value Name: GenerateCSFiles (this is the only acceptible value at this point)
Value : 1
Done! Load a BTS Project up, and compile - you'll see some changes.

Note: I have had this fail a couple of times on some huge BTS solutions with over 40 odd 'Solution Folders' (and bts projects under those etc).

Some great Webcasts coming up for November and December.

Check them out.

The 2007 Microsoft Office system: Watch, learn, enter to win!

Attend any live or on-demand webcast in this series through June 30, 2007, and qualify to win an Acer Ferrari laptop, Windows Mobile powered Smartphone, or Creative MP3/video player or Microsoft Zune (official rules). Offer open to residents of the U.S. only.