Israeli Web Developers Community (WDCIL) - September’s Meeting

Hi All,

The next meeting of the Israeli Web Developers Community will be held on September 7th 17:30-20:30, in Microsoft Ra’anana, Ha-Pnina 2 st.

You can register to the event in the following link (registration is free): http://wdcilseptember.eventbrite.com

You are also welcomed to visit WDCIL’s Facebook page: http://www.facebook.com/wdcil

The Future of Client Technologies

Which client technology is going to be dominant in the upcoming future? How alive is Silverlight? CanHTML5 really change the picture?

In this fast paced session we're going to see where both Silverlight and HTML5 are headed. We're going to discuss advances in the underlying technology, JavaScript, and see how we can build true smart client applications using HTML5 and JavaScript.

We'll explore new libraries and patterns in JavaScript; jQuery, unobtrusive script, KnockOut JS, Script# etc., and finish by having a glimpse at how Windows 8 is going to make it a whole new game.

Agenda:

17:30-18:00 - Gathering and Networking

18:00-19:00 - Future of Client Technologies, Part I

19:00-19:15 - Break

19:15-20:30 - Future of Client Technologies, Part II

About the speaker:

Elad Katz is a senior .NET architect at the Sela Group. He specializes in ASP.NET MVC, HTML5 and WPF/SL, with more than 10 years of experience in the industry in various .NET technologies.

What developers do when given a chance…

This photo was taken from an Airbus plane screen that belongs to air VIA

Note to QA: add a sanity test step to verify developers haven’t changed the icons.

These are the voyages of the airplane enterprise. Its continuing mission: to explore strange new countries, to seek out new sceneries and new civilizations, to boldly go where no one has gone before.

New course on the shelve – Advanced WCF

A few months ago I had my Advanced WCF workshop in Sela’s DevDays. The workshop was a great success and the classroom was packed with 50 people that came to learn about advanced WCF stuff such as monitoring techniques, performance considerations, best practices for client development, and ways to extend WCF.

I’m happy to announce that we have upgraded the 1-day intense workshop, added some new stuff that people wanted to hear about, and made it a 2-day advanced WCF course.

So if you would like to learn about advanced WCF techniques from the people who wrote Microsoft’s official WCF 4 course, give us a call and register for one of our next sessions (next course will open around December this year).

Course information and syllabus can be found in the following link:

http://sela.co.il/syl/syllabus.aspx?CourseCode=AdvWCF&CategoryID=165

This course will be in Sela’s Israeli branch, however I will be in Orlando, FL. during 5-9 of December for the Visual Studio Live! 2011 conference (look for me in the speaker’s list), so if you’re in the area and interested in attending this course let me know, and we’ll try to arrange a session of this course in the US.

WCF scaling – check your counters

A few months ago, I posted about the issue of WCF scaling and how it is affected by the throttling behavior, by ASP.NET settings (when hosted in IIS), and how it uses the thread pool.

Today I don’t want to talk about the scaling problem, but rather give you a small tip about how to check it – use performance counters.

WCF was shipped with built-in performance counter that show you various counters regarding throttling, security, MSMQ , WS-Reliable messages, and transactions.

To View these counters do the following:

1. Open your service configuration and add the following section in the <system.serviceModel>

<diagnostics performanceCounters="All"/>

2. Start your WCF service

3. Open the performance monitor utility (perfmon.exe)

4. Add a new counter. In the counters list, look for the counters that begin with “ServiceModel”, you should see three types of counters: Endpoint, Operation, and Service

- Endpoint counters lets you monitor a counter for a specific endpoint of your service

- Operation counters lets you monitor a counter for a specific operation of your service

- Service counters lets you monitor a counter for an entire service

5. For now, select the ServiceModelService counter for your version of WCF (ServiceModelService 3.0.0.0 for WCF 3.5, and ServiceModelService 4.0.0.0 for WCF 4), select the service that you started from the instances list, and click Add.

6. You will now see the performance counters in your graph. WCF performance counters have mixed ranges, so I usually prefer looking at them using the report view. So click the graph type button and select Report. You should see something like this:

7. Start you client application, and check how the counters change. The significant calls and instances counters are:

- Calls. The number of requests handled by the service since it was first activated.

- Calls Duration. Average latency of the service.

- Calls Faulted. Number of faulted requests.

- Calls outstanding. The number of requests currently processed.

- Instances. The number of service instances that are currently “alive” (running and idle).

- Percent of max concurrent calls. The percent of the achieved throttling. When you hit 100%, you will not be able to handle any more calls. The percentage counters were added in WCF 4.

For example, I ran a load test application on my service and after a minute or two got this result in the report:

You can see that I reached 100% throttling (100.781 percent to be exact), and I have 128 calls outstanding (currently processed requests) – this is because I have an 8 core machine, so the default max calls throttle is 16*8=128.

You can also see these 128 requests are handled by 128 instances, which means I’m probably using a perCall instancing mode. If I had used a single instancing mode, I would have seen only one instance.

Note: I have 128 instances and according to the default throttling settings the max instances should be 928 (max calls + max sessions = 128 + 800 = 928), so I should see 13% instance throttling, however the percent of concurrent instances is 0.
The reason the counter is zero is that if you don’t add the serviceThrottling behavior to your service, the default value of the max instances is set to Int32.Max which is 2147483647, and 128 out of 2147483647 is zero percent!. One you add the serviceThrottling behavior, the max instances will be calculated as the sum of the max calls and max sessions, unless you specify it directly.

So run your own load test on your servers, and see when you are hitting the throttling limit. After you change the throttling settings, retest your service, and verify that your average call duration is not affected by the increase in running threads.

WSDL vs MEX, knockout or tie?

When teaching WCF I am always asked about the difference between getting the service’s metadata by using the WSDL’s http get url, and getting the metadata by calling the MEX endpoint.

To answer that question we first need to understand the different parts of the configuration that affect metadata creation.

The ServiceMetadata behavior

This behavior controls whether metadata is created for the service. When this behavior is used, the service is scanned, and metadata is created for the service’s contracts (a list of operations and types exposed by the service).

If the behavior is not used, no metadata will be created for the service, and you will not be able to create MEX endpoints.

The ServiceMetadata’s httpGetEnabled flag

This flag defines whether the metadata will be accessible by an http get request. If this attribute is set to true, then a default url will be created for the metadata (usually the service’s address with the suffix of  ‘?wsdl’). The url will lead you to a WSDL file containing the description of the service operations, but without the description of the data contracts – these files are accessible by different urls, usually the service’s url with the suffix of ‘?xsd=xsdN’. The list of these urls are pointed out from the WSDL file.

If you do not set this attribute to true, you will not be able to access the metadata using http get requests. If you prefer using https for the get requests, you can use the httpsGetEnabled attribute instead of the httpGetEnabled.

There are several other settings for the get options – you can read more about them on MSDN.

The MEX endpoint

MEX endpoints are special endpoints that allow clients to receive the service’s metadata by using SOAP messages instead of http get requests. You can create MEX endpoint that can be accessed through http, https, tcp, and even named pipes.

The response that you will receive when calling a MEX endpoint’s GetMetadata operation will include the content of the WSDL and all the XSD files that are linked to it.

So what exactly is the difference between MEX and WSDL?

There is no difference!

MEX and WSDL both output the same thing – a web service description language (WSDL) document, only MEX does it by getting a SOAP message over some transport (http, tcp, named pipes) and returning one message with all the parts, while the WSDL urls use http get requests and require sending several requests to get all the parts.

Don’t believe me?

The following diff diagram was produced by comparing the output of a MEX call to the output of the aggregated results gathered by calling all the WSDL related urls using http get:

As you can see, there are only several sections that are different between the files (marked in red and yellow), while most of the content is identical. Let’s look at one of these parts:

The red lines come from the MEX result, and the yellow lines from the WSDL file. The difference is because when using WSDL files, the rest of the XSD files are linked by using the <xsd:import> tag with the schemaLocation attribute. Since the MEX response includes all the XSD content in it, the import tag doesn’t include the location attribute.

As for the other different sections – they are different because the MEX response wraps each WSDL/XSD part with an xml element that does not appear in the aggregated files. These elements are part of the MEX standard declared by the W3C - surprise surprise, MEX is a W3C standard, it’s not a Microsoft proprietary spec.

So they are the same, still, which one to use?

In most cases there is no need for MEX endpoint – using WSDLs with http get is usually enough.

The “Add Service Reference” option in Visual Studio 2010 will work for both options. The same goes for the svcutil command line tool.

So when would I use MEX?

1. If you want to make as less calls as possible to your service in order to get its metadata (one call instead of several).
2. If you don’t want to use HTTP to get the metadata, but prefer using TCP or named pipes (not so common).
3. If you want people to ask you why you declared a MEX endpoint.

So is it a knockout or a tie? I say tie.

Who changed my IIS 7.5 configuration?

I was asked today whether you can find out who was the last person to change the IIS 7.5 configuration files in case someone made a mess with the configuration.

This question is a decade-old question that bothers developers and IT all around the world - “Who touched my stuff?”

When talking about code changes in your applications, it is quite easy to open the source control tool you are using (VSS, SVN, ClearCase, TFS…) and search the history list for the person who recently changed the files.

When working with IIS configuration, it is a different story, because the configuration files of IIS 7.5 are not stored in a source control, and the only way to check who changed the configuration is by using security audits, if you’ve set them right in the GPO, and then check the event viewer’s security logs.

So what can we do in order to find out who is to blame? apparently, there is a simple way to do it, because IIS 7.5 sends trace messages for each configuration change it detects!

So to audit your configuration changes, just follow these steps:

1. Open the event viewer.
2. Expand Applications and Services Logs | Microsoft | Windows | IIS-Configuration.
3. Right-click the Operational option and select Enable Log.
   
4. From this point on, every configuration change that is made in IIS 7.5 will be logged, whether the configuration change causes the applicationHost.config to be changed or an application’s web.config file to be changed.
   Every configuration change will be logged with the information about the section that was changed, the value it was set to, the time, and most important – the user that was responsible for the change.
   

Now there are some important things to note:

1. The auditing process uses ETW which is a highly-performing infrastructure of the Windows operation system, so you shouldn’t see any noticeable CPU overhead.
2. It is advisable to limit the size of the log file that is created, because every small change to the configuration, such as creating a virtual directory, or changing the configuration of the application pool, will cause several log messages to be written.
3. Auditing is performed whenever you change the configuration through a controlled application, such as the appcmd.exe or the IIS Manager application. If the change is made by manually editing the configuration file (either the applicationHost.config or the web.config), the change won’t be audited.

By the way, a similar metabase auditing feature also exists for IIS 6. For more information on how to audit IIS 6 configuration changes, see the following TechNet article.

So turn on your logs and start catching those hooligans.

WCF configuration - using the correct service name

In the last couple of weeks, I’ve been seeing several questions posted in the MSDN’s WCF forum about problems loading or consuming services, which eventually are found to be because of a misconfigured service name in the WCF configuration section (the <system.serviceModel>|<services> section).

This is an example of a thread that ended by fixing the namespace in the configuration:

http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/348c1b12-c0fd-489c-8c5d-213cf4367565

And this thread was a bit trickier, but also ended with a “small” mismatch problem:

http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/044fc42b-859b-442d-b2b1-c209682a1d39

So let me just recap the purpose of the name attribute in the service section – when a service host is opened for your service type (which you pass in the constructor), the host searches the configuration file for the configuration of the service. A configuration file can contain configuration for numerous services, so the host tries to find the matching <service> element by checking the name attribute. The name attribute therefore should be set to one of the following:

The service class name:

The name attribute should contain the full name of the service class, including its namespace, so for example, if your service class is called Service1, and it is defined under the namespace TestApplication.Services, then the service configuration will be:
<service name=”TestApplication.Services.Service1” ...>…</service>

A fixed name:

Some people don’t like the concept of writing the name of the class and the namespace in the configuration files, especially when a long namespace is used. Therefore, there is another option – you can set a special “configuration name” for your service, and use that name instead of the namespace+class technique.
To set a special configuration name for your service, decorate your service class with the ServiceBehavior attribute, and set the ConfigurationName property to a fixed name, for example “myService”:
[ServiceBehavior(ConfigurationName="myService")]
public class Service1 : IService1 {…}

Now, all you need to do in the configuration file, is to set the name attribute to myService:
<service name=”myService” ...>…</service>

Side note – you can also use the ConfigurationName parameter in the ServiceContract attribute in order to give the contract a fixed name, and use it in your endpoint configuration, instead of setting the contract attribute to the full name of the contract interface.

Entity Framework 4.1– beware of the DbSet.Find method

One of the new features of Entity Framework 4.1 is the DbContext API which is basically a simplification of the ObjectContext API, and is intended to make your life a bit easier.

In this new API you can find the DbSet.Find method which according to MSDN does the following:

“Uses the primary key value to attempt to find an entity tracked by the context. If the entity is not in the context then a query will be executed and evaluated against the data in the data source, and null is returned if the entity is not found in the context or in the data source…”.

The section I underlined (“evaluated against the data in the data source”) is the one that you should beware of - the inner implementation of the Find() method creates a query that runs in the database and searches the entity set for the entity you want to find according to the ID which is passed to the method.

Now what’s wrong with the sentence I just wrote? it searches for the entity according to the ENTITY SET, not the entity type! This is a snippet from the implementation (using ILSpy):

If your model uses simple entity types, with no inheritance between them, you won’t have a problem with the Find() method, but… if your model contains an inheritance tree, and you try to use the method to find a derived type, then the method will create a query that searches the entire class hierarchy from the base type downwards – in all the child tables, instead of looking into the specific entity type’s table. This type of query will at the minimum take more time to execute because of all the joins between the tables, and in the worst case scenario – if you have many entity types mapped to different tables, it will crash because it will try to created a nested query with too many levels (check the “Query Complexity” section in the Performance Considerations for EF in MSDN).

What can you do? if you have a base type for all your entities, first ask yourself why you need the base type, since it usually creates problems with Entity Framework – there are several ways to overcome this, either by using interfaces, or by using base types not mapped to the EF model. If you do need the inheritance and do want to use the Find method’s technique of first looking in the loaded entities before searching the database, just write an extension method for the DbSet that first searches the loaded entities by looking in the DbSet.Local collection and if the entity isn’t found, run a SingleOrDefault query in the database.