Just another BloggingAbout.NET site

Menu

.NET

It will be used widely starting next week at PDC08 in Los Angeles. Expect lots of great announcements at this event.

For those attending PDC08, have fun, I am sure you will be amazed! For the not so fortunate who stay at home, the keynote sessions will be streamed live. All other sessions will be available as webcasts within 24 hours.

Quite a lot of people showed up. I went there with my colleague Erwin van der Valk. He was a Development Consultant, like I currently am, at Microsoft Services in the Netherlands. Erwin now works on the Patterns & Practices team at Microsoft in Redmond.

I took this picture of the entire group:

After dinner, a large portion of the group went to the Rock Bottom Restaurant and Brewery in Bellevue to continue the conversation. I had some really interesting discussions, over beer, with guys from several different product teams and a fellow MCS consultant based in Denver, CO. And not even all about Microsoft technology 😉

Too bad, I won't be able to attend this event in the near future again, unless I just happen to be in the neighborhood.

This morning I started stepping into the Windows Presentation Foundation. Before I knew it I was deep down into the internals of dependency properties and the Dispatcher object. The dispatcher has a nice old-fashioned message pump. I stepped into the dispatch of a message call onto a non-UI thread. Even though I already knew this, it is still startling to see that this translates into old-fashioned User32 Windows messages being send.

What really surprised me was to see a bit of VB code in a file that is called ExceptionFilterHelper.vb. According to the comment this file was needed because C#, unlike VB, does not support exception filters. However, the filter always returns true. According to the comment in the source code it is a "dummy stub to keep compiler happy, will not be replaced".

Something weird is going on here. The debugger shows I am in WindowsBase.dll!System.Windows.Threading.ExceptionWrapper.TryCatchWhen. The source code file shows the class MS.Internal.Threading.ExceptionWrapper.TryCatchWhen. Reflector can only find the former class. The disassembly of this class shows source code that is very different than what the MS source code server gives me.

This doesn't make much sense to me. Is the source code for this class deliberately hidden or is there some error in the source code lookup?

Since I haven't had my lawyer take a look at the license agreement that governs the source code access, I will not add a screen shot of the VB code 😉

Microsoft used the keynote in the SOA & Business Process Conference in Redmond to present its vision on the future of Service Oriented Architecture on the Microsoft platform. That vision and the wave of technology that will come with it, is codenamed "Oslo".

Long time Microsoft watcher Mary Jo Foley is very critical in her post called "Microsoft talks SOA futures but not dates". Mary Jo ends with "Microsoft has been struggling to prove to the market that it has a real SOA strategy. While the Redmondians are talking the right talk, the company is still a ways away from walking the SOA walk. Will customers wait or run off with other SOA vendors before Microsoft rolls out more than just a piecemeal SOA strategy?"

"Oslo" is obviously a Grand Vision. It will take a couple of years before this next wave of Microsoft technologies will ship. I thought that after the Longhorn reset/WinFX debacle and the "Whidbey" delays, Microsoft would not attempt to align so many technologies again in the future. But it is! "Oslo" comprises of at least:

BizTalk Server "6"

Visual Studio "10"

.NET Framework "4"

Systems Center "5"

BizTalk Services "1"

Some of the stuff presented reminded me of the grand WinFX, especially WinFS, vision that Microsoft presented at PDC03. We all know that WinFS never RTM-ed, despite enormous effort (many, many man years) put into it by Microsoft. Especially the term "Universal Editor" for the "Oslo" integrated modeling tool gave me the creeps. Sounds too much like: One tool to rules them all. One tool that spans the entire application development lifecycle: from its inception to its deployment.

Here are some screenshots from the new "Universal Editor" modeling tool that was demoed during the keynote:

Scott Guthrie did a major announcement on his blog yesterday: Microsoft will be releasing the source code for most .NET Framework libraries with the release of Visual Studio 2008. There will even be integrated support for debugging into framework classes and on-demand dynamic downloading of source files and debug symbols in Visual Studio 2008.

This is great news for .NET developers and a major step forward for Microsoft in my opinion. In and by itself it is enough reason to warrant an upgrade to Visual Studio 2008. In fact, I can think of no reason to keep using Visual Studio 2005 after the release of VS2008.

The source will be released under the Microsoft Reference License which basically means you can view and debug but not change or reuse the source code.

If you want a more liberal license you can look into Rotor aka the Shared Source CLI. Rotor was Microsoft's first effort for open sourcing a .NET CLI implementation. But Microsoft does not guarantee that Rotor has exactly the same codebase as the real .NET Framework.

Today I encountered a problem with accessing the metadata for a WCF service that was deployed on a Windows Server 2003 machine.

The WSDL part worked just fine for the metadata exchange endpoint (url?wsdl, url?wsdl=wsdl0, etc.). These WSDL files refer to XSD files for the message types. Requesting these files (url?xsd=xsd0, url?xsd=xsd1, etc.) resulted in an empty response from the webserver. Checking the IIS logs indicated a HTTP 200 OK response with 0 bytes transferred. A very weird problem. Checking the config files did not lead anywhere.

Eventually I found a hint in a reply by James Zhang in this MSDN Forum post. The identity that is used for the application pool that hosts the WCF service must have the correct NTFS permissions on the %WINDIR%temp folder. The identity that I used is a domain account. After setting the right NTFS permissions, the problem disappeared.

The funny thing was that this particular answer wasn't the answer for the original question in this forum post.

James Zhang does not indicate what type of permissions are needed, so I had to experiment a little.

First I added the account to the local Users group. This gives it special access permissions: Traverse folder/execute file, create files/write data, create folders/append data on this folder and subfolders. This is not enough. Then I realized, the domain account is already implicitly a member of this group because the Users group contains the NT AuthorityAuthenticated Users group. Next, I duplicated the extra rights that the NETWORK SERVICE account had for the domain account. These are list folder/read data and delete permissions for this folder, subfolders and files. This was enough. But it doesn't seem very secure. Now the service account can access temporary files created by other accounts.

So I experimented a bit more. I tuned back the NTFS permissions for the service account on %WINDIR%temp to list folder/read data on this folder only. This is just enough. This allows the account to see which files are in the temp folder, but it doesn't allow it to read the data in files that are owned by other accounts.

It is very unfortunate that WCF didn't give any clue about why it couldn't generate metadata in this case. It is also unfortunate that it needs just slightly more permissions that a standard user on the folder for temporary files.

Note that if you run your WCF service in an IIS application pool under the default NETWORK SERVICE account you won't run into this problem, because it has more than enough permissions.

PS: Best practices indicate you shouldn't deploy your services with metadata enabled. We will turn this off eventually. However, of course it should work if you do want to enable this.

Functionality of FlickrMetadataSynchr v0.8.0.0

It allows you to select a set of your photos on Flickr and a folder on your hard drive with images.

It reads the metadata for both Flickr images and the local images. The metadata that is read is:

Title

Description

Author

Tags

Geo-info (GPS coordinates)

Date and time taken

Last update date and time

It matches images on Flickr with local images based on the date and time taken.

It determines on a per picture basis in what direction the metadata should by synced, i.e., which side should be updated, if any. Currently the most recently updated side wins. I am getting help from Timo Proescholdt for a better algorithm that will allow for a merge of metadata, i.e., a two-way synch.

Workaround for WIC problems

During my holiday in France in July I received e-mail from Robert A. Wlodarczyk who works at Microsoft. He pinged me to say that he had released new sample code to update metadata using WIC. Yesterday, I tried to incorporate similar code into my application and ran into the same type of problems as before.

Because his sample was working, I wasn't ready to give up again. I finally tracked the problem down to a threading issue. WIC is throwing strange InvalidOperationException and InvalidFormatException exceptions with messages like "Cannot write to the stream" when it is called from a background thread. My app is multi-threaded so that the UI doesn't hang when it is busy syncing.

After I got confirmation from Robert that WIC indeed suffers from a threading issue, I solved the problem with a work around. I now marshal the call to the code that uses WIC to update metadata to the UI thread using the WPF Dispatcher object. This causes the app to become non-responsive for small amounts of time during the update of local metadata. But that is better than a non-fully-functional app.

Fully functional, give it a try

So all is well that ends well. After finally getting WIC to work, I could do away with the C++ code that was causing me headaches 😉 And my app now works on Windows XP again. You just need to have the .NET Framework 3.0 installed.

The Future

Even though the app is now able to sync metadata in both Flickr images and local images, there is always room for improvement. Here are my ideas, some of which are based of suggestions by people on CodePlex:

Improve the synchronization to also allow two-way synchronization for a picture pair. I.e., one side doesn't have to win. For example, if the Flickr image has just the title set and the local image the description, the metadata should be merged.

Add UI to see the match that is made by the tool and how it proposes to sync the metadata.

Allow you to exclude images if the match isn't good.

Allow you to overrule the sync proposal and sync the metadata in a different direction (on a per property basis) .

Add UI to store multiple mappings between Flickr sets and local folders. Currently the app only remembers the last folder and Flickr set that was used.

Add click-once deployment. That way the app can automatically check for new versions and update itself.

The first 30 minutes of this video are primarily about the internals. The last 10 minutes focus on the history of LINQ to SQL and how it relates to its "predecessors" Cω and ObjectSpaces. Matt and Luca also tell how Erik Meijer and Anders Hejlsberg got involved.

Check out the download on his blog post. It contains a more complete ValidatedQueryStringParameter class that supports other types besides Int32 like DateTime and Boolean. The QueryStringParameter already supports a Type property (of type TypeCode) to specify the type for the value of the parameter, so you can use it from markup like so: