לפני מספר חודשים נפתחו באתר מיקרוסופט MSDN ישראל פורומים לפיתוח ו-IT. בחודש האחרון חל שינוי בפורומים, בקטלוג שלהם, וברשימת מנהלי הפורומים. כחלק מהשינוי אני שמח לבשר לכם על פתיחתו של פורום חדש לתחום הווב בניהולם של שלמה גולדברג (הרב דוטנט) ועבדכם הנאמן.
בפורום ננסה לתת מענה לשאלות בנושאי פיתוח לעולמות הווב של מיקרוסופט – ASP.NET, ASP.NET MVC, Web Services, WCF, IIS, HTML/JS ועוד.
להבדיל מהפורומים של MSDN, הפורומים במיקרוסופט ישראל מיועדים לקהל הישראלי, כתובים בעברית, ומעודדים כתיבה בעברית של שאלות ותשובות.
למה בעברית? למה פורומים נוספים על אלו של MSDN? ובכן:
1. אנחנו לא היחידים – להרבה מדינות יש פורומים מקומיים, בשפה מקומית, שמיועדים לקהל המקומי.
2. עברית כשפת אם - לחלקנו קל להתבטא יותר בעברית במקום באנגלית. אני מכיר מפתחים מצויינים שעדין משתמשים בבודק איות לפני שליחת מייל באנגלית. כתיבה בעברית גם מאפשרת גישה לפורומים לקהל היותר צעיר של מפתחים.
3. יצירת קהילה – השתתפות בפורום תאפשר שיתוף פעולה יותר הדוק בין הקהל הישראלי והנציגים בארץ של מיקרוסופט. דרך הפורום נוכל ליידע אתכם על הרצאות בבתים פתוחים, כנסים בארץ,קורסים והכשרות. במקרים מסוימים ייתכן ואף נוכל לבצע אסקלציה של שאלות לגורמים במיקרוסופט ישראל ואף יותר מכך.
לצערנו, עד כמה שנרצה, פורום לא יכול להסתמך אך ורק על המנהלים שלו שיענו, ולכן ההשתתפות שלהם חיונית להצלחת הפורום. אז גם אם אין לכם שאלה ספציפית, אתם מוזמנים להכנס לפורום מדי פעם, להגיב על שאלות, ללמוד משאלות של אחרים, וגם לספר לנו על משהו מעניין שמצאתם שאולי יכול לשמש אנשים אחרים. אם אתם נוהגים לעבוד עם RSS, אתם מוזמנים להוסיף את לינק ה-RSS של הפורום לרשימות שלכם.
אז נתראה בפורום, בבלוג, בטוויטר ובאירועים השונים השנה.
As promised in my previous post, I’m continuing my mission to inform you of new changes in WCF 4.5.
This is the ninth post in the WCF 4.5 series. This post continues the previous posts on web-hosting features, and this time it is about the improved streaming capabilities of WCF when it is hosted in IIS.
Previous posts:
1. What’s new in WCF 4.5? let’s start with WCF configuration
2. What’s new in WCF 4.5? a single WSDL file
3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files
4. What’s new in WCF 4.5? Configuration validations
5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS
6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS
7. What’s new in WCF 4.5? BasicHttpsBinding
8. What’s new in WCF 4.5? Changed default for ASP.NET compatibility mode
If you’ve ever tried creating a WCF service that uses streamed requests (for example a file upload service) and host it in IIS, you may have noticed a strange behavior in your WCF service – it would seem that WCF is late in receiving the request, as if it was entirely loaded into the memory, and then passed to WCF. So is it streamed? or is it actually buffered? well, it’s both.
When you host a WCF service in IIS you also get a bit of the ASP.NET pipeline on the side, even if you don’t use the ASP.NET compatibility mode, this is documented in the WCF Services and ASP.NET article on MSDN (look for the part about the PostAuthenticateRequest event). In .NET 4, there is a design flaw in ASP.NET which causes the requests sent to WCF to be buffered in ASP.NET. This buffering behavior causes several major side-effects:
1. There is a latency between the time the streamed message is received by ASP.NET and the time the WCF service method is actually invoked.
2. There is some memory consumption due to the buffering – the exact amount of memory consumed depends on the size of the message sent by the client, but it can even get to several hundred MBs if you increase the MaxRequestLength of ASP.NET, the MaxAllowedContentLength of IIS 7, and of course the MaxReceivedMessageSize and MaxBufferSize of WCF.
3. When ASP.NET buffers the request, it uses both memory and disk. The requestLengthDiskThreshold configuration setting of ASP.NET controls when ASP.NET starts to use the disk. If you upload multiple files to WCF at once, you will start to see some delays due to multiple files being written to the disk at once. BTW, the files are written to an “upload” folder under the web application’s temporary asp.net folder (under c:\windows\Microsoft.NET\Framework\vX.X.XXXX\Temporary ASP.NET Files\) and are removed after the request is handled.
To show this behavior, I have created a client application that uploads a 500MB file to a WCF service. The WCF service is hosted in IIS and is set to a streamed request (you can download the StreamingInIIS sample solution from here). The following output shows some information about the time it took for the service to receive and handle the request, and the consumed memory:
1 Client started upload on 17/01/2012 19:03:25
2 Available memory before starting is: 2701MB
3 Client finished upload on 17/01/2012 19:03:44
4 Available memory after finishing is: 2699MB
5 Available memory on ASP.NET is: 2701MB
6 ASP.NET received upload at: 17/01/2012 19:03:28
7 Available memory on WCF is: 2122MB
8 WCF started receiving file at: 17/01/2012 19:03:38
9 WCF finished receiving file at: 17/01/2012 19:03:43
File size is: 524288000
Press any key to continue . . .
Some things to note about these results:
1. Client started / Client finished (line 1+3) – the total time the client waited for the service was 19 seconds; this includes the upload time, the buffering time of ASP.NET, and the time WCF handled the received stream.
2. ASP.NET started receiving the stream 3 seconds after the client began sending it (line 6).
3. WCF started receiving the stream 10 seconds after ASP.NET received started receiving it, and a total of 13 seconds from the time the client started sending it (line 8). In total, it took WCF 5 seconds to read the entire stream from ASP.NET (line 8+9).
4. Before the client sent the message, the available memory in the machine was 2701MB, which is also the available memory when ASP.NET first received the message. By the time WCF got the request and started handling it, the available memory was 2122MB – about 580MB were consumed from the memory for this operation (lines 2, 5, and 7).
5. As for the generated temp file, here is a screenshot of the temporary ASP.NET folder content:
Note: to show the ASP.NET information I used the ASP.NET compatibility mode. You can turn it off in the sample code if you want to verify that the problem also exists when we don’t use the compatibility mode (look at the difference between the time the client sent the request and the time WCF actually started handling the request – there should be a big latency).
So we get that WCF 4 doesn’t handle well streamed content over IIS, but what about WCF 4.5? what has changed?
In WCF 4.5 this just doesn’t happen – with .NET 4.5, ASP.NET doesn’t buffer the request, but rather forwards it directly to WCF, so we don’t get any latency, no memory consumption, and no disk usage.
Want to see some proof? I ran the same demo code in Windows Server 8 with WCF 4.5 over IIS. I used a smaller file size (200MB), since this is a VM with less memory, however you can still see the difference quite clearly:
1 Client started upload on 11/27/2011 7:23:18 AM
2 Available memory before starting is: 942MB
3 Client finished upload on 11/27/2011 7:23:46 AM
4 Available memory after finishing is: 942MB
5 Available memory on ASP.NET is: 941MB
6 ASP.NET received upload at: 11/27/2011 7:23:20 AM
7 Available memory on WCF is: 942MB
8 WCF started receiving file at: 11/27/2011 7:23:20 AM
9 WCF finished receiving file at: 11/27/2011 7:23:46 AM
File size is: 209715200
Press any key to continue . . .
First thing to note – memory consumption hasn’t changed throughout the execution – remains steady at ~942MB (lines 2+4+5+7).
As for the latency – WCF received the request at the same time ASP.NET received it (lines 6+8), which is 2 seconds after the client begins sending it.
Oh, and since ASP.NET passed the stream directly to WCF, no temp file was created !!
So there you have it – proper streaming in WCF 4.5 over IIS.
Stay tuned for more posts about the new features of WCF 4.5. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.
If you’ve been wondering where I disappeared to in the last couple of weeks, and if you are still waiting anxiously for my next post about WCF 4.5, fear not, I’m here, I’m alive, and I’m still kicking.
It’s been quite a rough month, as I have been occupied knee deep in home renovations. If you’ve ever dealt with contractors, technicians, and handyman, you know the type of frustration I’m talking about.
Between re-tiling my floors, replacing my kitchen cabinets, and re-painting my entire home, I also managed to find the time to deliver some courses on Windows Azure, IIS, Advanced WCF, Windows HPC Server, AppFabric Cache, and PowerShell.
2012 is going to be very productive year – this year is going to be a lot about the new releases of .NET 4.5, VS11, and Windows Server 8. I’m guessing you’ll see many more posts about the new features of WCF 4.5 (soon to come – a new post about the new streaming features of WCF 4.5 over IIS), .NET 4.5, and VS11.
I’m also continuing my voyage with BigData solutions which I’ve started last year with my work on the Windows HPC Server 2008 R2, and the new HPC labs we’ve created in Sela for the Windows Azure Platform Training Kit. This year is mostly going to be about Hadoop on Azure, so expect new labs and demos soon on the WAP TK (Windows Azure Platform Training Kit).
This year I will continue to manage the Israeli Web Developer Community (WDCIL) along with Gal Kogman, and in a couple of days I will also start to moderate the WebDev IL MSDN forum with Sholomo Goldberg, AKA the DotNet Rabbi.
I’m also continuing my speaking engagements this year, which ended last year with my sessions at VSLive Redmond and MCT Summit in October and VSLive Orlando in December. Other than my usual appearances at Sela’s SDP conferences in Israel, I will also be speaking this April in the Great Indian Developer Summit (GIDS) in Bangalore (India of course), and hopefully in additional conferences in Europe and the US (more information to come in the next couple of weeks).
So check out for my posts, my tweets, my courses, and my speaking engagements, and don’t forget – if you need me, just turn on the bat signal, and I’ll come to your rescue, just kidding – you can always contact me through my blog, my tweeter account, or send me an email, and I’ll do my best to answer you promptly.
Happy new year to y’all, enjoy the new leap year, and hopefully we’ll still be here to see 2013.
Yesterday I had two session in VS Live, one about the new features of WCF 4, and the other about the new way to develop web applications using ASP.NET MVC, the Razor view engine, jQuery, and IIS 7.5 Express.
The slide decks and demo code for both sessions can be downloaded from here: http://bit.ly/vslive-2011-orlando
I really enjoyed delivering both sessions, and congratulations to all the people that won Angry Bird balls for answering my questions, and for asking tough questions.
Hopefully we will meet in next year’s VSLive (if my sessions are picked up again).
Lately I’ve been writing and speaking a lot about WCF 4.5, but while delivering my “What’s new in WCF 4” session in Visual Studio Live yesterday I realized that there is one feature of WCF 4 that most people are not aware of, and do not really understand how useful it is – Standard Endpoints.
In WCF we always have to specify a set of address+binding+contract (ABC) for our endpoints. If our endpoints also need to be configured, for example – change the binding configuration, or the endpoint behavior, then we need to add some more configuration. We can use default configuration (another feature of WCF 4), but if we have two common settings, we cannot set two defaults and we’re back to square one.
Standard endpoints change the way we define endpoints – with standard endpoints we specify a special “kind” name in our endpoint, which automatically sets our endpoint’s address, binding, contract, binding configuration, and endpoint behavior.
For example – if we define the following endpoint:
<endpoint address="mex" kind="mexEndpoint"/>
The above endpoint will automatically be set with the mexHttpBinding and the IMetadataExchange contract.
If we define the following endpoints:
<endpoint address="web" kind="webHttpEndpoint" contract="MyNS.IMyContract"/>
We will get an endpoint which uses webHttpBinding, and automatically gets the webHttp endpoint behavior.
Although this is quite nice, this is the least we can do with standard endpoints. The real use of standard endpoints is when you create some of your own.
Image the following – you are a part of an infrastructure team in your organization and you need to explain to the dev teams which endpoint configuration they should use in their projects – “Please use NetTcp binding, with increased message size limits, with either security none or transport, and don’t forget to increase the send timeout”.
One way to do this is to send a memo to all the dev teams, hoping everyone follow your instructions to the letter. Another way you can do that is to create your own standard endpoint with all of the above configuration and just send it to the dev teams to use.
First of all you need to create your custom endpoint:
1: public class CompanyNameStandardEndpoint : ServiceEndpoint
2: { 3: private bool _isSecured;
4:
5: public CompanyNameStandardEndpoint(ContractDescription contract)
6: : base(contract)
7: { 8: this.Binding = new NetTcpBinding();
9: ResetBindingConfiguration(this.Binding);
10: this.IsSystemEndpoint = false;
11: }
12:
13: public bool IsSecured
14: { 15: get
16: { 17: return _isSecured;
18: }
19: set
20: { 21: _isSecured = value;
22: if (_isSecured)
23: { 24: (this.Binding as NetTcpBinding).Security.Mode = SecurityMode.Transport;
25: }
26: else
27: { 28: (this.Binding as NetTcpBinding).Security.Mode = SecurityMode.None;
29: }
30: }
31:
32: }
33:
34: // Receive a dynamic object instead of creating separate methods
35: // for netTcp, basicHttp, WSHttpBinding...
36: private void ResetBindingConfiguration(dynamic binding)
37: { 38: binding.SendTimeout = TimeSpan.FromMinutes(5);
39: binding.MaxReceivedMessageSize = Int32.MaxValue;
40: binding.MaxBufferSize = Int32.MaxValue;
41: }
42: }
Line 8 makes sure that your endpoint will use NetTcp binding.
Line 9 will call a method that initializes the binding settings (lines 36-41).
Note : the ResetBindingConfiguration method receives a dynamic object because for some reason some of the binding properties such as the MaxReceivedMessageSize and the MaxBufferSize are defined in each of the bindings instead of being defined in a base Binding class. The dynamic will allow us to change our code later on to support both TCP and HTTP bindings without duplicating our method for overloads.
Line 10 specifies that this is a user-defined endpoint and not a system endpoint.
Lines 13-32 are responsible of handling the user’s selection to whether the endpoint is secured or not by changing the security mode to either Transport or None.
So now we have a new standard endpoint that initializes the binding to NetTcpBinding, sets the timeout and message size, and knows to set the security according to the user’s selection. We can now add this endpoint in code to our service by calling the following code:
1: CompanyNameStandardEndpoint newEndpoint = new CompanyNameStandardEndpoint(
2: ContractDescription.GetContract(typeof(IService1)));
3:
4: newEndpoint.IsSecured = false;
5: newEndpoint.Address = new EndpointAddress(tcpBaseAddress + "companyUnsecured");
6:
7: host.AddServiceEndpoint(newEndpoint);
To be able to add this endpoint configuration in the config file, you will need to add some boilerplate code:
1: public class CompanyNameStandardEndpointCollectionElement :
2: StandardEndpointCollectionElement<CompanyNameStandardEndpoint, CompanyNameStandardEndpointElement>
3: { 4: }
5:
6: public class CompanyNameStandardEndpointElement : StandardEndpointElement
7: { 8: protected override ServiceEndpoint CreateServiceEndpoint(ContractDescription contractDescription)
9: { 10: return new CompanyNameStandardEndpoint(contractDescription);
11: }
12:
13: public bool IsSecured
14: { 15: get { return (bool)base["isSecured"]; } 16: set { base["isSecured"] = value; } 17: }
18:
19: protected override ConfigurationPropertyCollection Properties
20: { 21: get
22: { 23: ConfigurationPropertyCollection properties = base.Properties;
24: properties.Add(new ConfigurationProperty("isSecured", typeof(bool), false, ConfigurationPropertyOptions.None)); 25: return properties;
26: }
27: }
28:
29: protected override Type EndpointType
30: { 31: get { return typeof(CompanyNameStandardEndpoint); } 32: }
33:
34: protected override void OnApplyConfiguration(ServiceEndpoint endpoint, ServiceEndpointElement serviceEndpointElement)
35: { 36: CompanyNameStandardEndpoint customEndpoint = (CompanyNameStandardEndpoint)endpoint;
37: customEndpoint.IsSecured = this.IsSecured;
38: }
39:
40: protected override void OnApplyConfiguration(ServiceEndpoint endpoint, ChannelEndpointElement channelEndpointElement)
41: { 42: CompanyNameStandardEndpoint customEndpoint = (CompanyNameStandardEndpoint)endpoint;
43: customEndpoint.IsSecured = this.IsSecured;
44: }
45:
46: protected override void OnInitializeAndValidate(ServiceEndpointElement serviceEndpointElement)
47: { 48:
49: }
50:
51: protected override void OnInitializeAndValidate(ChannelEndpointElement channelEndpointElement)
52: { 53:
54: }
55: }
The above code is a basic configuration element code. The most important part is lines 13-17 in which you need to repeat each of the properties you created in the custom standard element (for a mapping between XML and CLR) and line 24 where you add all the properties that can be set in the configuration file, so the configuration can be validated.
Once you create the above code, you need just on more step to use the new endpoint kind in your configuration – you need to tell WCF that you have a new service endpoint. To do that you add the following XML in your <system.serviceModel> section:
1: <extensions>
2: <endpointExtensions>
3: <add
4: name="companyNameEndpoint"
5: type="TestWcfStandardEndpoints.CompanyNameStandardEndpointCollectionElement, TestWcfStandardEndpoints"/>
6: </endpointExtensions>
7: </extensions>
Note: On MSDN you can find a good explanation on standard endpoints, but the extensions configuration part is incorrect, the above configuration is the correct one (the correct element in the <extensions> is <endpointExtensions> and not <standardEndpointExtensions> as it appears in the article).
Now you are ready to declare your new endpoints and configure them:
1: <services>
2: <service name="TestWcfStandardEndpoints.Service1">
3: <endpoint binding="basicHttpBinding"
4: contract="TestWcfStandardEndpoints.IService1"/>
5: <endpoint address="mex"
6: kind="mexEndpoint" />
7: <endpoint address="companySecured"
8: kind="companyNameEndpoint"
9: endpointConfiguration="securedEndpoint"
10: contract="TestWcfStandardEndpoints.IService1"/>
11: </service>
12: </services>
13:
14: <standardEndpoints>
15: <companyNameEndpoint>
16: <standardEndpoint isSecured="true" name="securedEndpoint"/>
17: </companyNameEndpoint>
18: </standardEndpoints>
In lines 7-10 we define the endpoint with the new “kind” (line 9) and specify where we configure the rest of the endpoint (line 10).
Lines 14-18 contains the configuration of the standard endpoint which we created.
So to conclude, standard endpoints are an easy way to create fully-configured endpoints with binding configuration, contract settings, and endpoint behaviors. It’s mostly useful when wanting to create the same endpoint over and over again in multiple projects (which happens in 99.99% of the time).
Don’t bother copy pasting all the above code – you can just download the complete solution from here
Today I delivered a half-day talk about WCF on the following subjects:
- The new features of WCF 4.5
We talked about configuration simplicity, WebSocket and UDP support, streaming fixes for IIS, binary compression, and more. - Monitoring and troubleshooting WCF services (WCF 3.5/4/4.5)
We talked about performance counters, ETW, WMI, AppFabric, sniffing tools, tracing and message logging, instancing, concurrency, load tests and more.
According to the events website at http://events.microsoft.com, it looks like this was the first Microsoft event worldwide about WCF 4.5. We like new technologies in Israel 
.
We had a full-house (~100 people), got a lot of questions from people during and after the session, so it was lots of fun. I really enjoyed delivering the session, and I hope that in the coming year we will be able to see the RTM of Visual Studio 11 and .NET 4.5.
If you missed today’s session, you have another chance to hear me talk about WCF 4.5 in the November meeting of the Web Developers Community (WDCIL) this Tuesday in Microsoft Raanana. You can get more information and register to the event at http://wdcil2011nov.eventbrite.com
In the meanwhile, you can download the presentation and the sample code I’ve shown from my SkyDrive at http://bit.ly/wcf45msdn – this also includes the WCF 4.5 demos I showed, so don’t forget to install VS 11 and .NET 4.5 (preferably on a VM).
I want to repeat what I told people in the event today – the WCF team is eager to know what you think about WCF, what is missing in WCF to make your work easier, and if you encountered any bugs in the product. There are several ways by which you can contact them:
If you want to read more about WCF 4.5, check out previous posts I published. I will publish new in-depth posts on the new features, so stay tuned. You can also follow me on Twitter @IdoFlatow
1. What’s new in WCF 4.5? let’s start with WCF configuration
2. What’s new in WCF 4.5? a single WSDL file
3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files
4. What’s new in WCF 4.5? Configuration validations
5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS
6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS
7. What’s new in WCF 4.5? BasicHttpsBinding
8. What’s new in WCF 4.5? Changed default for ASP.NET compatibility mode
If you want to learn more about WCF, check out the following WCF sessions we have at Sela’s DevDays next week:
If you are not familiar with our user group, the Israeli WDC user group is a meeting place for web developers, designers, and architects, where we discuss new and existing web technologies, best practices in web development, and any other interesting stuff that relates to the web world. The user group is managed by Gal Kogman and yours truly, with the support of Microsoft Israel.
This is just a short list of things we talked about in previous meetings:
- ASP.NET MVC
- Win8, HTML5, and JS libraries
- jQuery mobile framework
- Beyond Visual Studio 2010 – Lightswitch, NuGet, IIS Express …
- Javascript and jQuery tricks
- Facebook for developers
- Rich application for the browser – EF, WCF, Ajax, and jQuery
You can read more about the user group on our Microsoft page (a bit outdated), and for the latest news and information, I suggest you visit our Facebook page.
So what’s the purpose of this post, you ask? I’m writing this post to let you know that we are always looking for potential speakers - the field of web development is very vast, and many of us deal with all sorts of web technologies and techniques, so if you think you have worked with a special technology you want to share with the community by presenting it in one of the meetings, please let me know by email or by writing in our Facebook wall. You don’t need to be an experienced speaker to present at the meetings, just make sure you don’t have stage freight beforehand 
.
This is the eighth post in the WCF 4.5 series. This post continues the previous posts on web-hosting features. This post is about the ASP.NET compatibility mode default change of WCF 4.5.
Previous posts:
1. What’s new in WCF 4.5? let’s start with WCF configuration
2. What’s new in WCF 4.5? a single WSDL file
3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files
4. What’s new in WCF 4.5? Configuration validations
5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS
6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS
7. What’s new in WCF 4.5? BasicHttpsBinding
Normally, a WCF service hosted under IIS works side-by-side with ASP.NET – they share some of the pipeline, they have the same application domain, but work quite independently of each other when it comes to the HTTP context (authorization, context, session, etc…). This is the default behavior of WCF.
However, you can change the default behavior of WCF and set it to ASP.NET compatibility mode – this allows WCF and ASP.NET to share most of the pipeline, and have the same HTTP context. This has some advantages and some disadvantages (such as the problem of ASP.NET sessions and blocking WCF calls).
To make WCF use the ASP.NET compatibility mode you need to do the following two changes:
1. Enable ASP.NET compatibility mode for the hosting environment in your web.config:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
2. Set each of your services to support the compatibility mode, by adding the AspNetCompatibilityRequirements attribute.
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
You can read more about WCF and ASP.NET on MSDN.
So what has changed in WCF 4.5?
In WCF 4.5 the default behavior of WCF is to support the ASP.NET compatibility mode automatically. This is achieved by the following changes:
1. In the WCF Service Application project template, the aspNetCompatibilityEnabled attribute was added to the serviceHostingEnvironment element, and it is set to true by default.
2. The default value of the AspNetCompatibilityRequirements attribute has changed from NotAllowed to Allowed. Without this changed default, you would have needed to manually add the attribute to every new service. This is noticeable in the attribute’s documentation:
WCF 4 - http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute.requirementsmode(v=VS.100).aspx
WCF 4.5 - http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute.requirementsmode(v=VS.110).aspx
ASP.NET compatibility mode is very useful if you need to use share information between your ASP.NET application and WCF service in regards to the HTTP context, session, or user authorization, but be careful of the concurrency problem that occurs when sharing session state between WCF and ASP.NET.
Expect more on ASP.NET and WCF in next posts, so stay tuned. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.
The RTM of .NET 4.5 is still to come, and I assume many of you are still adjusting to WCF 4. If you want to learn more about the new features of WCF 4, come to my session at Visual Studio Live! 2011 in Orlando (December 5-9).
Today I had my WebDev session about the new technologies related to web development:
- ASP.NET MVC 3
- Razor view engine
- jQuery
- NuGet
- IIS Express 7.5
I enjoyed the session very much, and by the amount of tweets it looks like I wasn’t the only one.
I hope no one got hurt from my flying balls 
You can download the session’s slides and the two demos I showed from here: http://bit.ly/vslive-2011-redmond
I’m off to San-Francisco tomorrow for the North-America MCT summit. Visual Studio Live – thanks for having me, I will see you all again in VS Live Orlando in December.
Yesterday I had my WCF 4 session in VS Live, where I showed some of the new features of WCF 4, including:
- Configuration simplification
- IIS hosting features
- WebHttp improvements
- Routing services
- Discovery services
I also talked a bit about some other new WCF 4 features such as the DataContractResolver type, the new ReceiveContext API for MSMQ bindings, Monitoring WCF with ETW and PerfMon, the new binary stream encoder, and the new throttling defaults.
Those of you who stayed till the end also heard about some of the new features that will be in WCF 4.5.
So if you’ve missed the session, had to step outside for an important call, or you just want to try out the samples I showed, you can go ahead and download the slides and samples from here: http://bit.ly/vslive-2011-redmond
This is the seventh post in the WCF 4.5 series. In previous posts we’ve examined two new security features of WCF 4.5 and IIS – multiple client credentials support, and default HTTPS endpoint support, both new features are IIS-specific (or to be more exact, web hosting specific). In this post we will look into a new security configuration option in WCF 4.5 – the BasicHttpsBinding.
Previous posts:
1. What’s new in WCF 4.5? let’s start with WCF configuration
2. What’s new in WCF 4.5? a single WSDL file
3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files
4. What’s new in WCF 4.5? Configuration validations
5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS
6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS
Transport security is supported in WCF since day 1, and you can configure it by setting the security mode of your binding:
<bindings>
<basicHttpBinding>
<binding name="secured">
<security mode="Transport">
<transport clientCredentialType="Windows"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
Declaring transport security based endpoints is quite an easy task in WCF, but does require writing some binding configuration in the config file. WCF 4.5 helps reduce the amount of configuration by adding a new type of binding – basicHttpsBinding.
The basicHttpsBinding is similar to basicHttpBinding, only it has the following defaults:
- Security mode = Transport
- Client credential type = None
Setting up an endpoint with a basicHttps binding is quite simple:
<services>
<service name="WcfServiceLibrary1.Service1">
<host>
<baseAddresses>
<add baseAddress = "http://localhost:8733/Design_Time_Addresses/WcfServiceLibrary1/Service1/" />
<add baseAddress = "https://localhost:44310/Design_Time_Addresses/WcfServiceLibrary1/Service1/" />
</baseAddresses>
</host>
<endpoint address="" binding="basicHttpBinding" contract="WcfServiceLibrary1.IService1"/>
<endpoint address="" binding="basicHttpsBinding" contract="WcfServiceLibrary1.IService1"/>
</service>
</services>
If you want to change the default client credential type for the secured endpoints, you will need to create a binding configuration for the secured endpoint:
<bindings>
<basicHttpsBinding>
<binding>
<security>
<transport clientCredentialType="Windows"/>
</security>
</binding>
</basicHttpsBinding>
</bindings>
Note: Since this is a secured binding, the security mode can be either Transport or TransportWithMessageCredential only. TransportCredentialOnly is not supported for this type of binding.
Stay tuned for more posts about the new features of WCF 4.5. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.
The RTM of .NET 4.5 is still to come, and I assume many of you are still adjusting to WCF 4. If you want to learn more about the new features of WCF 4, come to my session at Visual Studio Live! 2011 in Redmond (October 17-21).
Also, if you are an MCT and reside in the US, come hear my session about WCF 4 at the MCT 2011 North-America Summit that will be held in San-Francisco (October 19-21).
This is the sixth post in the WCF 4.5 series. In the previous post we’ve discussed new authentication features for services hosted in IIS, and this post is continuing the new IIS hosting features list - automatic HTTPS endpoints in IIS.
Previous posts:
1. What’s new in WCF 4.5? let’s start with WCF configuration
2. What’s new in WCF 4.5? a single WSDL file
3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files
4. What’s new in WCF 4.5? Configuration validations
5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS
So what is the automatic HTTPS endpoint feature? WCF 4 introduced the default endpoint feature which enables the service host to automatically create default endpoints if no endpoint has been specified for the service. The default endpoints are created for each of the service host’s base addresses, according to a mapping between a base address scheme (HTTP, TCP…) and a matching binding. For example, if you have an HTTP base address, you will get an endpoint that uses the BasicHttp binding.
So what’s new in WCF 4.5? we now get another scheme mapping for HTTPS, so if your IIS has SSL enabled, and you don’t have any specific endpoints specified for the service, you will get both HTTP and HTTPS endpoints. The default binding for the HTTPS scheme is the same as for the HTTP scheme – BasicHttp binding.
How can you enable this feature?
1. Set up SSL in your IIS; there’s an excellent tutorial for this in the IIS.NET website.
2. Create the WCF service and host it in a web application.
3. Set the web application to be hosted in IIS.
4. Verify that the service doesn’t have any endpoint configuration set for it, so it will use default endpoints.
That’s it!
If you now browse to your service’s WSDL file, you will notice that you get two default endpoints – HTTP and HTTPS:
See anything strange? you are right! for some reason the two endpoints use different machine names in the address.
Since WCF 4, services hosted in IIS automatically use the useRequestHeadersForMetadataAddress behavior which constructs the endpoint host name according to the host name used in the WSDL GET request. This behavior is required especially for web farms where clients see a special host name and not the machine name itself, but as you can see, the automatic HTTPS endpoint does use the machine name for some reason, which can be a bit problematic when the IIS server is a part of a web farm.
If you have SSL set in IIS, but you’re not interested in having an HTTPS endpoint, you can remove it by removing the HTTPS scheme mapping as shown in the following XML configuration:
<system.serviceModel>
<protocolMapping>
<remove scheme="https"/>
</protocolMapping>
. . .
</system.serviceModel>
This new feature is very useful if you need HTTPS endpoints, since before this feature if we needed HTTPS endpoints, we couldn’t use the default endpoints and had to declare all endpoints manually, both HTTP and HTTPS. This is another step for making configuration files smaller.
Unfortunately, there is currently the bug of the host name, I hope it will be resolved by the time the new framework is released.
Stay tuned for more posts about the new features of WCF 4.5. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.
The RTM of .NET 4.5 is still to come, and I assume many of you are still adjusting to WCF 4. If you want to learn more about the new features of WCF 4, come to my session at Visual Studio Live! 2011 in Redmond (October 17-21).
Also, if you are an MCT and reside in the US, come hear my session about WCF 4 at the MCT 2011 North-America Summit that will be held in San-Francisco (October 19-21).
October began yesterday with an email from Microsoft congratulating me for receiving Microsoft’s Most Valuable Professional (MVP) award. I’m a connected system developer MVP, which kind of describes my work – working with distributed systems, connecting clients and servers, building WCF services, ASP.NET applications, working with IIS servers, etc…
This is the first time I receive the MVP award, so I’m quite excited. Special thanks to the people who helped with my nomination – Guy Burstein and Meir Pinto from Microsoft Israel, to my managers at Sela Group – David Bassa and Ishai Ram, and of course to all of you that are reading my blog, that come to my sessions in conferences, to the hundreds of people I trained over the years, and to those whose nickname I only know that marked my answers as correct in forums. Congratulations also to my colleagues in Sela – Arik Poznanski for his new MVP in Visual C#, and to Gil Fink for his third year in a row of being a Data Platform MVP.
As I said before, this month bears many good news – next week I’m heading to Microsoft HQ in Redmond, where I’m going to attend an Azure Platform Metro course. Metro courses are special Microsoft courses that are constructed by DPE teams in Microsoft (developer and platform evangelists) and are intended to teach new technologies for eager developers. I’m going to participate in this course with several other trainers from all over the world, and learn the newest stuff in the Azure platform from Microsoft’s experts, so it’s going to be a great experience for me, and I’m very much looking forward to it.
October goes on with good stuff – the following week after the course I’m going to attend the Visual Studio Live! conference in Redmond (17-21 of October), this time not as a listener, but as a speaker.
I’m giving two sessions in the conference, about the new features of WCF 4, and about the new face of web development – ASP.NET MVC, jQuery, and Razor.
And for the finale of October – after my two sessions, I’m catching a flight to San-Francisco to attend the North-America 2011 MCT Summit (Microsoft Certified Trainers Summit), which is also during 19-21 of October. In the summit I will be presenting yet again the new features of WCF 4, but will also probably spend some time talking about teaching tips for the official WCF 4 course (10263A) that I co-authored last year for Microsoft.
If you are working in the area of Seattle or San-Francisco, and interested in WCF consulting or training, let me know as I have a few days off that I can dedicate to consultations and courses. I will be available in the Seattle area between 14-17 of October, and in the San-Francisco area between 21-22 of October. I also have a 9-hour connection in Newark on the 23rd, if you want a quick consultation 
October started great with my new MVP, and it’s going to end great with two weeks of learning and speaking in the US.
This is the fourth post in the WCF 4.5 series, and a direct addition to the previous post, since I neglected to mention something important about editing configuration files in WCF 4.5 and Visual Studio 11 – validations during editing and compilation.
Previous posts:
1. What’s new in WCF 4.5? let’s start with WCF configuration
2. What’s new in WCF 4.5? a single WSDL file
3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files
In my last post I mentioned the problems we face when manually configuring services in the configuration file (app.config / web.config), mainly when dealing with service names.
In WCF 3.5 there was less problem using wrong service names, since there had to be at least one endpoint for each service, and if you have used the wrong service name in the configuration – you would have gotten an exception.
But with WCF 4 the rules have changed because of default endpoints – you haven’t configured any service endpoint? no worries, the service host will create some for you, according to your base address. This causes many people to not notice they have used the wrong service name, and thus get endpoints that often aren’t the ones they wanted, for example getting a default basicHttp endpoint instead of a netTcp endpoint that was declared in the configuration.
In comes WCF 4.5, or to be more exact Visual Studio 11, with it’s configuration intellisense, and as we’ve seen in the previous post, the intellisense gives us the option to select which service class to configure. Another good thing that comes out of it is warnings – if you use the wrong service name in the <service> element you will get a compilation warning, as shown in the following screenshot:
The validations also apply to other parts of the configuration, such as contract names, binding names, and binding / behavior configuration names, as can be seen in the following screenshot (I added the highlights).
Although useful, the last type of validations is less crucial, since usually if you got the name of the service correctly, and misspelled one of the other names, that would cause an exception while opening the service host, so at least you’ll know about it, unlike using the wrong service name.
So to conclude – Intellisense, cool! Tooltips, cool! Validations, also cool! WCF 4.5 – very cool!
Stay tuned for more posts about the new features of WCF 4.5. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.
The RTM of .NET 4.5 is still to come, and I assume many of you are still adjusting to WCF 4. If you want to learn more about the new features of WCF 4, come to my session at Visual Studio Live! 2011 in Redmond (October 17-21).
Also, if you are an MCT and reside in the US, come hear my session about WCF 4 at the MCT 2011 North-America Summit that will be held in San-Francisco (October 19-21).
This is the fifth post in the WCF 4.5 series. This time we will demonstrate one of the new cool features of WCF 4.5 and IIS hosting – creating an endpoint that supports multiple authentication types.
Note: The authentication mechanism in the following post refers to client authentication used in the HTTP transport (the Authorization HTTP header), either when using a secured transport (HTTPS) or a non-secured transport (HTTP).
Previous posts:
1. What’s new in WCF 4.5? let’s start with WCF configuration
2. What’s new in WCF 4.5? a single WSDL file
3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files
4. What’s new in WCF 4.5? Configuration validations
When hosting WCF services in IIS, a lot of developers struggle with the problem of declaring authentication types, since there are two places where you need to set the authentication type – in the service’s configuration and in the IIS configuration.
If you don’t set the two properly, meaning if there is a mismatch between the endpoint’s authentication types and IIS’s authentication types, you might end up getting an error message like this:
The authentication schemes configured on the host ('Basic, Anonymous') do not allow those configured on the binding 'WSHttpBinding' ('Negotiate'). Please ensure that the SecurityMode is set to Transport or TransportCredentialOnly. Additionally, this may be resolved by changing the authentication schemes for this application through the IIS management tool, through the ServiceHost.Authentication.AuthenticationSchemes property, in the application configuration file at the <serviceAuthenticationManager> element, by updating the ClientCredentialType property on the binding, or by adjusting the AuthenticationScheme property on the HttpTransportBindingElement.
The message informs you that you’ve declared basic and anonymous authentication in IIS, but you are trying to use Negotiate (Windows authentication using Kerberos) in your service configuration which isn’t supported by the host (IIS).
Since this is very annoying, WCF 4.5 enabled you to inherit the authentication types from IIS, so you only need to declare them once.
So how do we do that? It took me some time to understand how to set it up, since this is one of the new features which is not so documented; To save you the trouble, here is a set of instructions you’ll need to follow:
1. Create a service and host it in IIS.
2. Define the service’s endpoint to use any of the HTTP bindings (basicHttp, wsHttp…).
3. Create a binding configuration for the endpoint, and set the security to either Transport, or TransportCredentialsOnly (in basicHttp).
4. In the transport’s configuration, set the clientCredentialType attribute to InheritedFromHost – this is a new value that was added in WCF 4.5. This value is currently not documented in MSDN.
At this point, your service configuration might look like so:
<services>
<service name="MyService">
<endpoint address="" binding="basicHttpBinding" contract="Mycontract" bindingConfiguration="secured"/>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="secured">
<security mode="Transport">
<transport clientCredentialType="InheritedFromHost"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
Note: if you use basicHttpBinding, you can use either transport security or transportCredentialsOnly security (use the last option only when not using basic authentication). For wsHttpBinding, you need to use transport security to get the InheritedFromHost credential type option.
5. Open IIS, and set the authentication types to the ones you require – anonymous, basic, digest, NTLM, windows, or certificate. Of course you can set several of these options.
6. After setting the authentication types in IIS, try browsing to the service’s WSDL file and check the reported authentication types:
<wsp:ExactlyOne>
<http:NegotiateAuthentication xmlns:http="http://schemas.microsoft.com/ws/06/2004/policy/http"/>
<http:NtlmAuthentication xmlns:http="http://schemas.microsoft.com/ws/06/2004/policy/http"/>
</wsp:ExactlyOne>
Note: Anonymous authentication is not shown as an authentication type in the WSDL. For the list of authentication types that can appear in the WSDL file, check this MSDN article.
7. On the client-side, add a service reference to your service. The generated configuration will be set according to the authentication types you set in IIS:
a. If you set a single authentication type, then the configuration will be set to it. For example basic, if you set basic authentication, then the configuration will be set to basic credentials:
<basicHttpBinding>
<binding name="BasicHttpBinding_IService1">
<security mode="Transport">
<transport clientCredentialType="Basic" />
</security>
</binding>
</basicHttpBinding>
b. If you set multiple authentication types in IIS, then things get a bit trickier. The client-side doesn’t have a matching “InheritedFromHost” attribute, and it can’t include more than one transport element, so the credential type is usually set to the first credential type specified in the WSDL. For example if you only use basic and digest, then it’s likely you will see digest authentication in the client’s credential type:
<wsHttpBinding>
<binding name="WSHttpBinding_IService1">
<security mode="Transport">
<transport clientCredentialType="Digest" />
</security>
</binding>
</wsHttpBinding>
If you only set IIS to support anonymous authentication, then the client binding configuration will look like so:
<wsHttpBinding>
<binding name="WSHttpBinding_IService1">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</wsHttpBinding>
One small thing to note regarding the default configuration – basicHttp and wsHttp have different default values for client credential type; if the authentication type in IIS is the binding’s default credential type, then you will see the following client binding configuration (this example is for the wsHttp binding):
<wsHttpBinding>
<binding name="WSHttpBinding_IService1">
<security mode="Transport"/>
</binding>
</wsHttpBinding>
The default client credential for basicHttp is none, and the default for wsHttp is Windows. So for the above example, the binding configuration was generated because the IIS was set to Windows.
I think that Microsoft should have invested a bit more on managing the configuration on the client side for this feature – it’s not clear to the client-side which authentication types are supported, and the generated configuration is only set to one of them. Another thing is that if you use anonymous authentication in IIS, it doesn’t show in the client configuration unless it is the only available authentication type.
To conclude, without this feature, we need to declare several endpoints, one for each credential type, but our clients will able to see exactly which credentials the service expects; With the new feature, we only need one endpoint, and the rest is configured in IIS, but our clients will have more trouble understanding what is available to them.
My score for this feature: Server-side +1, Client-side –1.
Stay tuned for more posts about the new features of WCF 4.5. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.
The RTM of .NET 4.5 is still to come, and I assume many of you are still adjusting to WCF 4. If you want to learn more about the new features of WCF 4, come to my session at Visual Studio Live! 2011 in Redmond (October 17-21).
Also, if you are an MCT and reside in the US, come hear my session about WCF 4 at the MCT 2011 North-America Summit that will be held in San-Francisco (October 19-21).
More Posts
« Previous page -
Next page »