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 […]
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:
With .NET 4, the service configuration can be simplified to the following:
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:
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:
The new WCF service configuration improvements in .NET 4 allow us to greatly simplify this service configuration to look like this:
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:
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!
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. “.
…
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: …
…
line 8: Invalid xsi:type qname: ‘d:string’ in element …@http://…
<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>
How to work around this?
Is it the error in the response message?
Is it an error in the WCF-BasicHttp adapter?
There are a few capabilities advertised in the Microsoft ESB Toolkit for BizTalk Server that I have yet to try out. One thing that seemed possible, although I hadn’t seen demonstrated, was the ability to sequentially call a set of BizTalk maps.
Let’s say that you have maps from “Format1 to Format2″ and “Format2 to Format3.” […]
Originally posted by Nick Heppleston at: http://www.modhul.com/2009/06/29/configuring-biztalk-for-disaster-recovery-part-1/
I’m often surprised by the lack of disaster recovery capability organisations have for BizTalk, the novel (read: ‘unsupported’) approaches taken to provide a theoretical level of cover that is then never tested, or the lengthy procedures (24 hours +) for a task that should be as simple as pressing […]
Originally posted by Nick Heppleston at: http://www.modhul.com/2009/06/29/configuring-biztalk-for-disaster-recovery-part-1/
I’m often surprised by the lack of disaster recovery capability organisations have for BizTalk, the novel (read: ‘unsupported’) approaches taken to provide a theoretical level of cover that is then never tested, or the lengthy procedures (24 hours +) for a task that should be as simple as pressing […]
While preparing for my webcast on the WCF-SQL Adapter as part of a series of webcasts* I ran into a requirement that is quite frequent with BizTalk solutions: merging the contents of a flat file with a SQL Server database table. I wrote a post a while ago on how call the same stored procedure […]
Hi all
Recently, I posted a post about handling mapping to and from a comma separated list.
You can find it at http://blog.eliasen.dk/2009/06/22/HandlingCommaSeparatedValuesInsideAMapPartI.aspx
I came to think that this was actually also a great opportunity for me to develop
my first cumulative functoid. The functoid is then supposed to take the values as
input and output the list of values with a comma in between them.
The functoid has been developed and added to my functoid library at http://eebiztalkfunctoids.codeplex.com –
free to download. Also another functoid in the library, which has been there for a
while is the “CSV Extract” functoid which extracts a specific position from a separated
list.
—
eliasen
It was a logn time ago, so, I guess, it’s ok to tell this story at last…
Well, everybody knows what “checkin” is, right? That’s when you send your updated, fixed or new code to the depository for safekeeping. There is a lot of systems for that. OpenSource guys usually use CVS for that, there are other commercial ones like PVC, Microsoft has the one of its own called “source depot”, as well as SourceSafe.
All they do is just one thing: enable you to restore a previous version if somebody broke the current one. Also, to keep a special version for this very-special-big-corporate-customer, which is not easy, but at least possible with the version control. AFAIK, we don’t do that at Microsoft, but one of the companies, I worked before for, had about three major branches for critical customers like Chevron.
Of course, that’s not panacea, and when 10+ developers start to checkin their changes left and right,… well… the result is normally not that encouraging. Everybody has his features working standalone, but making it work together becomes a challenge. Actually, we had such a period in our life at the early stage in Windows Home Server. We had a lot to do, and VERY little time to accomplish it. Guess what? Nightly tests become broken and did not want to run no matter what. As a little token of pride, I’d like to mention that tests for my features worked fine — I was responsible for communications between server and the clients. Which means that when my areas are broken, half of the product tests would fail instantly, so I had to keep my parts in shape. But most of other areas weren’t that lucky and overall tests package did not want to run no matter how angry the management was and how actively we as a team were fixing the problems.
Then we found a solution… I had a toy Garfield in my office. After speaking with one of the leads and the manager, we introduced the following rule: to make a checkin, you should have Garfield in your hand. So, you get Garfield, run the tests, if all pass, you do checkin, and give Garfield away to the next one in the line. A sort of a physical mutex preventing concurrent changes.
People hated Garfield. Enough to say that in a couple of weeks my boss put it on the eBay! Don’t believe it? See for yourself!
Well, nobody bought it, nevertheless the problem was solved. In three days all the tests were running fine again and never broke again in several weeks. And after the Thansgiving 2006 Garfield was sent to the honorable retirement, while we continued in a more easy way but still without breaking the tests…
By the way, Garfield is still around. It’s hanging in my office on the corkboard, reminding the team’s veterans of the old times 🙂
Starting Monday morning I will be starting a new project for a client of my employer Improving Enterprises. I’ve spent a good deal of time talking with my new teammates about what technologies we will be using for the project, and I thought that work might be of interest to others, so here are some of the highlights.
The first thing that was decided, during the initial scoping phase of the project, was that this project was a nearly ideal candidate for Visual Studio 2010 and .NET 4.0. How did we come to that decision? The desired architecture for the project is such that certain features of WCF 4.0 and Entity Framework 4.0 would help with the implementation, and the timeline of the project is such that we have a no concerns over the current lack of the a “Go Live” license. For language it was decided we will primarily be working in C#. With that decided, we get to the far more interesting pieces.
Obviously we are going to need an IoC container for the project, and we have settled on StructureMap for that. The competition in this regard was Castle Windsor as Improving has the benefit of employing Craig Neuwirt, we knew we had an expert. The final decision to go with StructureMap instead hinged on two related things, complexity and learning curve. While we were quite certain we could pick up Castle quickly enough (2 of the 3 did not know it already), we were not as certain how easy it would be for those who follow us. StructureMap had a single well defined scope (IoC), versus the larger bite that the Castle Project would be for those who follow. We recognize we could have just done Windsor, but we found no compelling reasons to do that versus StructureMap.
As noted, we will be doing a good bit of WCF 4.0 on this project, so it naturally followed we would need to integrated StructureMap into the channel stack to let it handle the creation of our service instances. Jimmy Bogard has an excellent post on this subject, and we followed that guidance closely, though we updated the StructureMapServiceHostFactory to use ObjectFactory.Initialize as was recommended by the excellent ObsoleteAttribute usage in the latest StructureMap.
Even within a group of people as passionate about creating great technology as we have at Improving, there are certain debates that deeply divide us. Source Control is definitely one of them. We have a certain segment of the company that are passionate advocates for Team System, obviously including Chris Tullier our resident Team System MVP. But there are others who are passionate believers in Subversion. Still others are not happy with either of those options, and still seek the “better mouse trap” for Source Control. We discussed the pros and cons of various solutions and decided in the end to try GIT, because of its distributed model, and see how we liked it in comparison to the others. It is an experiment, and we shall see.
Really, is there another option? The definitive logging library for .NET, it does what it needs to and does not bring along any additional baggage. As we are also using StructureMap, we found this blog post by John Rudolf Lewis helpful in discussing how to inject log4net using StructureMap (or Ninject) without losing fidelity in the logs.
So there are a few of our technology decisions, things I’ll be learning on in the coming months more and more.