Have you ever wondered if/when a transaction in WCF upgrades to the DTC? There two simple ways to check this:

1. Open Performance Monitor and add a new counter. Get the counter Active Transactions from the Distributed Transaction Coordinator section.
2. Open Component Services and go to My Computer in COM+. There is a folder for Distributed Transaction Coordinator, through which you can view the DTC statistics.

In both cases, you'll see the active transactions jump from 0 to 1 when a transaction upgrades to DTC. This happens when you cross a service boundary. If you just use a transaction within the service, WCF will stick to the Lightweight Transaction Manager as long as you stay within you AppDomain or access a single database (SQL Server 2005 and up).

For those of you that attended my sessions in Dallas, here are the demo's for

• POX/REST Strategies with WCF (194.22 KB)
• Understanding Transactions in WCF (396.18 KB)

If you attended the latter, you'll remember that I wrecked my prepared demo (note to self: never change configs just before a session). I finally figured out what was wrong. I changed some configuration on the server side and I thought I did the same on the client. Apparently I did not, because when I updated the service reference on the client it worked.

At a session about ASP.NET DynamicData at VSLive in Dallas, one of the attendees asked me about my thoughts of DynamicData becoming a part of ASP.NET MVC. I commented that currently DynamicData is very much based on the current ASP.NET paradigm of pages and controls, whereas ASP.NET MVC is not. ASP.NET MVC presents a new way of thinking to the ASP.NET world and I find it hard to believe that millions of developers will jump on the ASP.NET MVC bandwagon immediately after its release (let's face it, it hasn't even been released yet) and leave their old coding styles behind. You need to learn to think differently first. Also, if ASP.NET MVC becomes the primary ASP.NET paradigm, there is a whole lot of code that is still using ASP.NET the way most of us do at the moment. That said, ASP.NET MVC is very interesting.

Ok, so back to the original question. If you look at Scott Guthrie's post about the ASP.NET MVC Release Candidate, you'll see that there is scaffolding support on based on the model, instead of table based scaffolding using in ASP.NET DynamicData. The model based scaffolding enables you to create different views of the model in no time.This is very cool, because it provides you with way more control over what is happening than in DynamicData. And because it is based on the model, you're not tied to database objects, but rather to business objects. How you persist those is up to you.

I still think ASP.NET DynamicData and ASP.NET MVC are going to live side-by-side for quite a while, and that they will use concepts that were created for one or the other. The main reason for this belief is based on my earlier comment: I think ASP.NET MVC and ASP.NET "Classic" will run side-by-side for a loooooong time. I do feel that ASP.NET MVC ultimately provides us with more flexibility and will at some point become the more dominant paradigm.

 

At VSLive in Dallas last week I promised to follow up with a post about securing an ASP.NET Dynamic Data application. Your first concern is not exposing all the tables, so although it demo's well, never set ScaffoldAllTables to true. That however, does still not solve how you can provide read-only access to certain users, while providing edit access to others. The most elegant way to do that is at the Data Model level, using a custom security attribute. There's a great sample on how to do that on the Dynamic Data Samples on Codeplex. The specific sample you want is Secure Dynamic Data.

If you don't want to spend the time to understand how security at the Data Model works, you can also just use ASP.NET Roles to secure specific parts of your site. Since securing folders/files that way has been around since ASP.NET 1.x, that should be easy enough :). There is a gotcha though: you cannot secure dynamic folders. In other words, a Dynamic Data path /SomeTable/List.aspx is not securable, because SomeTable is not an actual folder. With three simple steps you can get around this.

Step 1: Create a folder corresponding to a specific role, for example "Readers".

Step 2: Create a web.config in that folder limiting access to the role(s) you want to give access.

Step 3: In globas.asax, route the tables and actions that apply to the specific role to that folder, like this:

routes.Add(new DynamicDataRoute("Readers/{table}/{action}.aspx")
{
    Constraints = new RouteValueDictionary(
        new
        {
            action = "List|Details",
            table = "EvaluationSubjects|Reports",
        }),
        Model = model
});

 

I will be speaking at VSLive! again, this time in Dallas from 8 until 11 December. I'll be doing the following sessions:

• Introduction to ASP.NET Dynamic Data (Tuesday 9 December, 11:15 AM)
• POX/REST Strategies with WCF (Thursday 11 December, 1:45 PM)
• Understanding Transactions in WCF (Thursday 11 December, 4:45 PM)

VSLive! is a very nice and relaxed event with great content. So it's a great opportunity to learn new stuff and new people. If you want to attend the Dallas show and see me speak, you can get a $300 discount by entering the discount code SPVAN. I hope to see you there.

I've been working on a small Windows Mobile app and I had a really weird problem. While working in the emulator everything worked fine. However, when I deployed it to my Smartphone (HTC S710), it didn't show the labels. Textboxes etc. worked fine, but the labels didn't show up, no matter what I did. Some of the things I tried:

• redeploy
• changing the font of the labels
• making sure there was no overlap between labels and textboxes

It took me about an hour to get it working. I went into the settings and because there wasn't anything about screen/font settings I finally looked at those of the startup screen (option 4), thinking that this didn't have anything to do with my app. As it turned out the culprit was a color scheme that I downloaded from the Windows Mobile site called EarthView.

I while ago I created the control shown below. It acts a multi-select ListBox from the API perspective, but works by selecting items and moving them over. Pretty much all elements can be styled, such as the headers, the ListBoxes and the buttons. I'd love to have one with some JavaScript that allows drag-n-drop, but that's too much work for me. Feel free to copy and extend the source code(3.15 KB).

Microsoft heeft ten aanzien van jQuery een opmerkelijke stap gemaakt. In plaats van zelf iets jQuery-achtigs te maken, heeft Microsoft aangekondigd jQuery zelf te gaan ondersteunen en nieuwe onderdelen van ASP.NET AJAX op jQuery te baseren. Dit is zowel door jQuery als door Microsoft bevestigd. Ik ben hier persoonlijk zeer verheugd over en ik hoop dan ook van harte dat Microsoft deze lijn doorzet. Ik heb veel liever dat Microsoft ondersteuning biedt voor (toonaangevende) bibliotheken dan er zelf een (vaak minder goede) kopie van te maken. Overigens is het niet alleen zo dat Visual Studio jQuery technisch gaat ondersteunen, maar ook dat klanten van Microsoft support kunnen krijgen via Microsoft. Ik ben benieuwd of er nog meer gaat volgen in deze richting.

I run a a development team and we're working on some functionality that we're likely going to share between different projects. The problem is that part of the functionality are some adminstration pages that we want to be able to develop separately, deploy as part of customer's. The requirements we have are roughly the following

1. We can version the pages separately, so that when we patch the shared functionality, we don't have to rebuild/redploy the entire site.
2. We don't have to copy files from one project (the project with shared functuionality) to another (the project that is customer specific).
3. In our source control the customer's website is really a separate project and not a branch of the project with shared functionality.
4. The administration pages should be themed to the customer's site and additional admin pages may be added custom for the customer's website.

The best way, we figured, was to deploy the shared functionality as a seprate assembly, similar to a precompiled website. A precompiled website however is one thing, AFAIK you can't dump two precompiled websites into the same application. I did figure out a way to deploy the site as an assembly, by putting the admin pages inside an assembly as an embedded resource. We then pull the pages out using a VirtualPathProvider. There are great implementations out there using the VirtualPathProvider, such as serving a website from a ZIP-file and from a database (which is what SharePoint does).

If you don't know what a VirtualPathProvider is, let me quickly fill you in. When ASP.NET gets an aspx page for the first time, compiles that page and stores the result in a system directory. Only when you change the file will ASP.NET recompile the page. Now, the file system that ASP.NET gets the page from is virtualized, which means that ASP.NET does not know how the underlying file system is implemented. By default this is the normal Windows file system, but you can create a provider that uses another storage mechanism. As long as it works just like the file system, this will work fine. You can use a database, XML file, ZIP file, web service, or whatever as the underlying file system. All you have to do is create a few classes, including an implementation of the VirtualPathProvider, register the provider in global.asax, and you're off. The great thing is that because you're supplying ASP.NET with the page, your page benefits from ASP.NET (pre)compilation. This means that if you build a CMS with content in a database, the database is only hit the first time the page is requested and the content is compiled into the page.

So, what we can do is put the aspx pages inside an assembly as an embedded resource and serving the pages from there. Because the pages are inside a regular .NET assembly, it can be linked into a project and be updated when there is a patch, without affecting the application's it is contained in. All we have to do is redeploy the assembly. It sounds a bit weird, but it actually works, as you can see in the attached demo (51.54 KB). Be aware that this is really just a demo. It is just meant to prove it works. The logic to get directories is flawed (which has something to do with the fact that directories are not preserved in embedded resources), and possibly more is. However, you can access the following pages:

• \AdminHome.aspx
• \Default.aspx
• \NewFolder1\HTMLPage1.htm (only works in VS webserver or IIS7 in integrated mode)

Default.aspx is kind of funny, because the code behind class is compiled in the class and the page itself embedded. Enjoy!

LINQ to SQL ontwikkelt heerlijk als je weet dat je alleen tegen SQL Server hoeft te praten. Maar LINQ to SQL voegt wel weer een extra laagje toe, waardoor de kans groot is dat er vertraging optreedt. Hoewel... LINQ to SQL doet ook aan caching, dus als je veel met dezelfde data moet werken, hoef je niets extra's to doen om code aanzienlijk sneller te laten lopen dan wanneer de database iedere keer benaderd moet worden. Rico Mariani geeft in vijf delen een aardig inzicht in de performance van LINQ to SQL en wat je kunt doen (of niet hoeft te doen) om de performance te verbeteren. Het eerste deel, met links naar de andere delen, vind je hier.