WF 3.5 Hands On Labs Updated

The ten Windows Workflow Foundation (WF) hands-on labs were updated today on Microsoft download center for your coding enjoyment!

These ten labs were initially posted when WF was new to the world and .NET 3.0 was hot off the presses. This past winter, the product management team worked with David Starr to get the labs converted to .NET 3.5 and Visual Studio 2008, make the manuals consistent, and bring the VB.NET code up par to follow the same best practices as the C# code.

Once installed, you will have the following labs installed on your machine:

  • WF01: Getting Started with WF
  • WF02: Creating Custom Activities with WF
  • WF03: Hosting Workflows in WF
  • WF04: Creating State Machine Workflows in WF
  • WF05: Communicating with the Host Application for WF
  • WF06: WF and Web Services
  • WF07: Creating Rules Driven Workflow in WF
  • WF08: Transactional Behavior in WF
  • WF09: Modifying Workflow Models at Runtime with Workflow Change in WF
  • WF10: Embedding the Workflow Designer for WF

About half the labs saw some significant updating and clean-up – and they should yield a greatly improved experience for the learner; we applied feedback from HOL participants who took the labs at our events and provided an evaluation. The second half of the labs were more simply migrated and cleaned up for consistency.

But wait! There’s more! 🙂

While we were at it, we added an eleventh lab to the mix. Because the labs were developed before the new WCF activities were introduced, we dug into the excellent Visual Studio 2008 training kit done by the DPE folks, we updated and cleaned up the lab that walked a user through using the new WCF Send and Receive activities for WF in .NET 3.5:

  • WF11: Workflow Enabled Services and Other New Features in the .NET Framework 3.5

The product management team will be making three additional hands-on labs available in the near future: unit testing WF workflows (currently available on MSDN Virtual Labs), unit testing WCF services, and advanced context management in WF 3.5 (built by Matt Milner, and unveiled at TechEd 2009 North America). All three labs have scored pretty well at events, and we’re looking forward to sharing them with you for direct download.

We hope that you find these updated labs useful; and, as always, welcome your feedback and comments.

Enjoy!
– Cliff

Visual studio crash when trying to add pipeline components to toolbox

Visual studio crash when trying to add pipeline components to toolbox

I ran into a very strange issue today. After installing the ESB Toolkit, I tried to ’Choose Items” in the pipeline components toolbox:

But every time I did that Visual Studio 2008 just closed without warning and the following exception appeared in the Application event log:
“ .NET Runtime version 2.0.50727.3074 – Fatal Execution Engine Error […]

SolZip version 1.1 has been released

Hi all

A friend and colleague of mine has just release SolZip version 1.1 on CodePlex – Find
it here: http://solzip.codeplex.com/.

Basically, it is a nifty way of zipping a Visual Studio 2008 C# solution. The utility
is pointed towards the .sln file and then zips all files in the solution and projects
into one zip file.

To me this is really nice, because as of BizTalk 2009, the project files are just
specialized C# projects and therefore, it seems to work just fine for BizTalk 2009
solutions as well. I can use it when blogging to quickly zip up a solution to attach
to a blog post without having to zip the entire folder and then deleting the large
dll files and other silly stuff. SolZip just takes what is necessary.

I was the very first downloader of the 1.1 version – you should go download it now!
🙂



eliasen

Dublin TAP program open for nominations

Microsoft is pleased to announce that nominations are now being accepted for participation in the “Dublin” Technology Adoption Program (TAP). “Dublin” rounds out the existing application server capabilities in Windows by providing additional features to help organizations manage and run Windows Communication Foundation (WCF) services and Windows Workflow Foundation (WF) services built using .NET 4.

The TAP is a program designed for customers who have specific business needs to get early access to new technology and to drive their requirements into the current and future versions of the product. In return, TAP participants help Microsoft reach its quality bar across product, documentation and support services and help validate features and use cases in real world environments. Customers receive direct support by Microsoft and are able to deploy pre-release builds into production if needed.

TAP requires significant time and resource commitment, so all nominations are required to have a compelling business need, appropriate resources and executive support to join this program. Additionally, due to the cost of running such a program, there are a limited number of seats available.

Should TAP not be suitable for you, Microsoft will also be offering a public beta later in 2009, which will enable you to evaluate the technology only in development and test environments.

We are accepting nominations now and will continue to accept nominations until August when the program is scheduled to start or until capacity is exceeded. Because “Dublin” needs WCF and/or WF 4 services to manage, we want to accept organizations into the program as soon as possible so that work can commence on the service development side prior to “Dublin” availability for TAP customers in August/September.

To submit a nomination to the “Dublin” TAP please go to :https://connect.microsoft.com/dublintap. (You will need to be logged into a LiveId account to access this site.)

Many interesting tools and utilities for MOSS 2007 in codeplex!

Many interesting tools and utilities for MOSS 2007 in codeplex!

Without a doubt, SharePoint 2007 or MOSS 2007 is the most popular and sought-out skill from Microsoft Gold Partners and Customers across various industry sectors.
Eventhough, Microsoft has been constantly upgrading lot of new features with latest service pack releases, there are still some features & utilities which are desired by sharepoint developers.However, Codeplex contains many […]

MVVM???

MVVM???

Recently, i heard one of my colleagues enquire about MVVM model. MVVM stands for Model-View-ViewModel in WPF framework (also called as Onyx).
Onyx is a framework that aids in the development of WPF applications that follow the Model-View-ViewModel pattern. The biggest reason for following this pattern is to allow you to unit test as much of […]

Invoke & edit your Facebook profile from your web application

Invoke & edit your Facebook profile from your web application

Facebook.NET provides a .net library for use in developing Facebook applications and accessing Facebook APIs. The library primarily geared around and optimized for developing ASP.NET-based Web applications, both FBML and IFrame-based Facebook applications through an intuitive API and small set of server controls. It does support the use of the Facebook API from desktop applications […]

Service Configuration Improvements in .NET 4

Hello! I am Amadeo Casas Cuadrado, Program Manager in the Connected Framework team. I would like to introduce some of the new .NET 4 features (available with .NET 4 Beta1!) that we have developed to simplify the user experience when configuring WCF services.

One of the main pain points for Windows Communication Foundation (WCF) users has traditionally been dealing with large configuration files for their services. The WCF configuration schema is complex and provides users with many hard to find features. In .NET 4, we have focused on helping WCF users configure their services. We will be shipping new WCF features in .NET 4 for this reason.

The first feature consists of removing the need for explicit per-service configuration. If you do not configure any <service> elements for your service, and your service does not define programmatically any endpoint, then a set of endpoints will be automatically added to your service, one per service base address and per contract implemented by your service. In each of these endpoints, the endpoint address will correspond to the base address, the binding will be determined by the base address scheme and the contract will be that one implemented by your service.

For instance, the following configuration snippet represents the traditional configuration that a traditional WCF developer would create. Here we see a service that has one base address and implements one contract:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <services>

      <service name="Service1">

        <host>

          <baseAddresses>

            <add baseAddress="http://localhost:8731/Service1/" />

          </baseAddresses>

        </host>

        <endpoint address=""

                  binding="basicHttpBinding"

                  contract="Library1.IService1" />

      </service>

    </services>

  </system.serviceModel>

</configuration>

 

With .NET 4, the service configuration can be simplified to the following:

 

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

</configuration>

 

Even better in this case, you could also deploy your service with no configuration file at all!

It is also possible to customize the mapping between base addresses schemes and binding types. For instance, if you need to increase the security of your service and use wsHttpBinding as the default binding for HTTP addresses, the following chunk of configuration will do the trick:

   

<protocolMapping>

  <add scheme="http" binding="wsHttpBinding" />

</protocolMapping>

 

The second feature enables the user to define default values for WCF bindings and behaviors. Those bindings, service behaviors and endpoint behaviors with no name will be applied to your services with no explicit configuration. If we take a look at the configuration generated for a WCF Service Library project in VS2008/.NET 3.5:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <services>

      <service name="Service1"

               behaviorConfiguration="Service1Behavior">

        <host>

          <baseAddresses>

            <add baseAddress="http://localhost:8731/Service1/" />

          </baseAddresses>

        </host>

        <endpoint address=""

                  binding="wsHttpBinding"

                  contract="Library1.IService1" />

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior name="Service1Behavior">

          <serviceMetadata httpGetEnabled="True" />

          <serviceDebug includeExceptionDetailInFaults="False" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

</configuration>

 

The new WCF service configuration improvements in .NET 4 allow us to greatly simplify this service configuration to look like this:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <behaviors>

      <serviceBehaviors>

        <behavior>

          <serviceMetadata httpGetEnabled="True" />

          <serviceDebug includeExceptionDetailInFaults="False" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

</configuration>

 

This is, in fact, exactly how the new VS2010/.NET 4 service configuration template will look like.

The fact that you can define defaults for bindings and behaviors is particularly useful in the WCF configuration inheritance model in .NET 4. Those bindings and behaviors that are defined in upper levels in the configuration hierarchy will be added to your services with no explicit configuration. The following diagram shows an example of how it is possible to simplify your service configuration by relying on configuration elements defined at the machine or the application level:

 

In this example, a default basicHttpBinding and a default serviceMetadataBehavior are defined at the machine level. At the next level of the hierarchy, a default serviceDebugBehavior is defined, which will be added to the service, as well as a default endpoint which uses the binding defined at the machine level. As a final note, in .NET 4 Beta 2 all those default service behaviors will be merged and added to the service with no explicit configuration. Stay tuned!

Finally, the third WCF configuration improvement added in .NET 4 is the standard endpoint, which will allow you to define reusable preconfigured endpoints. The main characteristic of these endpoints is that one or more of the address, binding and contract properties have a fixed value. This is particularly useful to define system endpoints that provide their own contract implementation, i.e. not defined by your service, as for instance the MEX endpoint, whose implementation is provided by WCF out of the box. Another interesting feature in the standard endpoints is the possibility of extending the service endpoint with new properties, in a similar way as it is done with the custom bindings. The standard endpoints will also allow you to define custom properties for your service endpoint.

In order to define standard endpoints, you will need to make use of the following properties in your endpoint. The first property is kind, which identifies the standard endpoint type, and must be registered in the <endpointExtensions> section. The second property is endpointConfiguration, which will match the configuration element name of the standard endpoint in the <standardEndpoints> section, used to define the new properties for the endpoint. The last property is isSystemEndpoint, which will flag the endpoint to determine whether it has a fixed contract provided by WCF out of the box or not.

For instance, the following chunk of configuration code defines an udpDiscoveryEndpoint, which has an implicit contract and defines extra properties to the endpoint:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <services>

      <service name="Service1">

        <endpoint address=""

                  binding="basicHttpBinding"

                  contract="Library1.IService1" />

        <endpoint kind="udpDiscoveryEndpoint"

                  endpointConfiguration="udpConfig" />

      </service>

    </services>

    <standardEndpoints>

      <udpDiscoveryEndpoint>

        <standardEndpoint

                  name="udpConfig"

                  multicastAddress="soap.udp://239.255.255.250:3703"

                  … />

      </udpDiscoveryEndpoint>

    </standardEndpoints>

  </system.serviceModel>

</configuration>

 

What is next?

These features will help you maintain a cleaner configuration model for your WCF services. Let us know what you think!

And this is not the end of it! There are cases in which you will want to have different configuration settings for your services, one for debugging and one for deployment, for instance. In this case, you still need to develop and maintain different web.config files, or to have large chunks of unpleasant commented-out settings. We are currently working on the possibility to define configuration profiles, which will act as bags of different configuration elements that will be imported by the service using that profile. More coming shortly!

BizTalk WCF-BasicHttp adapter issue with http://www.w3.org/2001/XMLSchema namespace

BizTalk WCF-BasicHttp adapter issue with http://www.w3.org/2001/XMLSchema namespace
I am using the WCF-BasicHttp adapter to consume outer Web-service and getting the error (actually if I have retry>0, I am getting Warning first. See below:
Event Type:Warning
Event Source:BizTalk Server 2006
Event Category:BizTalk Server 2006
Event ID:5743
Date:…
Time:…
User:…
Computer:…
Description:
The adapter failed to transmit message going to send port “…” with URL “…”. It will be retransmitted after the retry interval specified for this Send Port. Details:”Unable to read the stream produced by the pipeline.
Details: The value ‘d:date’ is invalid according to its schema type ‘http://www.w3.org/2001/XMLSchema:QName’ – ‘d’ is an undeclared namespace. “.
or (After retry the previous message the retry limit for this port)
Event Type:Error
Event Source:BizTalk Server 2006
Event Category:BizTalk Server 2006
Event ID:5754
Date:…
Time:…
User:…
Computer:…
Description:
A message sent to adapter “FILE” on send port “…” with URI “…” is suspended.
Error details: Unable to read the stream produced by the pipeline.
Details: The value ‘d:date’ is invalid according to its schema type ‘http://www.w3.org/2001/XMLSchema:QName’ – ‘d’ is an undeclared namespace.
MessageId: …
InstanceID: …
Very srange. When I tried the same Web-service with SoapUi, the result of the verification of the Response message is similar.

line 8: Invalid xsi:type qname: ‘d:string’ in element …@http://…
What is wrong with response message?
Response Message:
<e:Envelope xmlns:d=”http://www.w3.org/2001/XMLSchema” xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” xmlns:wn1=”…” xmlns:wn2=”…” xmlns:wn0=”…” xmlns:e=”http://schemas.xmlsoap.org/soap/envelope/”>
<e:Body>
<wn2:ActionResponse>
<wn2:MyResponse i:type=”wn2:MyResponseType”>
<wn2:Detail i:nil=”true”/>
<wn2:MyMsg i:type=”wn2:ArrayOfMyMsgType”>
<wn2:MyMsgType i:type=”wn2:MyMsgType”>
<wn2:MsgDescriptionText i:type=”d:string“>…</wn2:MsgDescriptionText>
<wn2:MsgIdentificationID i:type=”d:string“>…</wn2:MsgIdentificationID>
<wn2:MsgSeverityLevelCode i:type=”wn2:MsgSeverityLevelType”>…</wn2:MsgSeverityLevelCode>
<wn2:MsgSourceText i:nil=”true”/>
</wn2:MyMsgType>
</wn2:MyMsg>
</wn2:MyResponse>
</wn2:ActionResponse>
</e:Body>
</e:Envelope>
Investigation discovered that the issue is in the namespace prefix “d“. If I change it to the “xsd“, the error disappeared.
Questions:
How to work around this?
Is it the error in the response message?
Is it an error in the WCF-BasicHttp adapter?
How to work around this issue?
I changed the WCF-BasicHttp port for the old SOAP port and SOAP port works fine.
Is it the error in the response message?
I didn’t find any limits for the “http://www.w3.org/2001/XMLSchema” namespace and for prefixes for it. The only limit is “don’t use the prefixes, started with ‘xml’ letters”. It is the common practice to use “xsd” prefix for the “http://www.w3.org/2001/XMLSchema” namespace. But it is not the rule.
Seems the WCF-BasicHttp adapter is “too smart”.
Is it an error in the WCF-BasicHttp adapter?
possible…