Ok maybe it's not just released but still I'm happy to finally put the word out that you can now install Mayando v1.2 directly from the Microsoft Web Application Gallery!

Mayando is a full-featured photo blogging application that you can use to showcase your photos online.

What's new in this release:

• Dates on photos are now hyperlinks to other photos taken or published on the same date.
• The Flickr photo provider no longer synchronizes machine tags (because they are not intended to be displayed).
• You can now configure the photo provider to synchronize automatically at regular intervals (e.g. every 60 minutes).
• You can also use a command-line client application (or if you're a developer, a client API) to remotely trigger a photo provider synchronization through the use of a new Service API.
• You can now filter the event log by severity.
• Mayando is now compatible with ASP.NET "medium trust" hosting providers.
• You can now disable distributed transactions (in the AppSettings.config file) if your hosting provider does not allow them. Note that this can cause data loss and/or corruption so only change this if you accept the risks associated with disabling transactions.

If you want to see it running: check out the Mayando Demo Site or of course my own photo blog.

Since it’s been almost two years since my last blog post, I figured I owed the remaining 3 subscribers of my blog a short update on what I have been up to...

#1 – Maya

There have indeed been a couple of interesting things going on, and first and foremost, that would include the birth of our amazingly beautiful and unbelievably cute daughter Maya in June last year :-)

She just turned one year old this week, so time flies indeed! If you would be interested in seeing some more pictures, then I’m sure you can figure out where her own website would be located if you studied the incredibly complicated naming pattern I used to locate my own website :-)

#2 - Mayando

Because Project #1 called for a way to keep the family up to date and to regularly show off exactly how cute Maya is, and (almost equally importantly) because I was looking for an excuse to learn ASP.NET MVC, I decided to write a photo blogging web application. “What, another photo gallery site”, you might ask? Eh, yeah, exactly. But in my defense: I looked hard at the existing ones and couldn’t find one that covered my requirements so this is one I built to fit my needs :-)

Nonetheless, I didn’t just want to build a one-off “baby web site for Maya”, but really a generic application that I could also use later on use as the engine for my own photo blog – and that you, dear reader, might also want to use if you want to publish a collection of photos in a nice and user-friendly way. (For example, I have an architect friend who is interested in using it as a portfolio site for the houses he designed.)

And so, Mayando was born: a full-featured photo blogging application that you can use to showcase your photos online.

Now I did not want to reinvent solutions to the problem of globally storing and serving images on the web, so I figured that I should only build a rich front-end on top of existing photo storage services such as Flickr. So I built a provider model where the URL’s of the photos and their details (and comments) just get “sucked in” from a photo sharing site and you can work with them from your own website. So basically, the photos get pulled in from a service such as Flickr and then displayed through Mayando, using a lot of navigation possibilities (by creating static pages and dynamic galleries, by browsing through photos, comments, tags, dates, ...).

It also allows visitors to post new comments and obviously I needed to handle comment spam so again I implemented a provider model for anti-spam services (such as Mollom).

And finally, the whole thing had to be easily customizable so I made sure to allow different themes for the photo blog’s look and feel, with customization options ranging from simple (e.g. simply changing the CSS stylesheet) to advanced (completely changing the entire site layout and/or individual pages). Thankfully, by now I know that the ASP.NET MVC framework is so flexible it easily let me do all this with surprisingly little effort. Anyway, I won’t go into the many details – if you’re interested in how it works: it’s open source so feel free to look at the Mayando source code and let me know if you want to contribute!

If you just want to see it running: check out the Mayando Demo Site or of course my own photo blog :-)

#3 – Flickr Schedulr v1.4 & v2.0

Because Project #1 and Project #2 meant I would be using Flickr more, I figured it was also time to give my Flickr Schedulr application an update to incorporate feedback from a number of users.

In case you’re wondering what it is: Flickr Schedulr is a Windows desktop application that automatically uploads pictures to Flickr based on a schedule (e.g. to post a new picture every day at a certain time). It allows you to create a queue of pictures to be uploaded, along with their titles, descriptions, tags, and the photosets and groups into which they should end up.

I published v1.4 last January; new features include the possibility to upload multiple pictures at a time in batch, better handling of multiple selected files and overall UI improvements.

I’ve also been working really hard on v2.0 which is a complete rewrite of the application in Windows Presentation Foundation (WPF), and as such looks and feels so much nicer in many ways than the previous version. It will also have a few new features of course. I’m still polishing some things but you can expect to see a release in the next few weeks.

Since I’ve been very happy with CodePlex for my other projects, I decided to move the source code and work items there and lo and behold: here is the new Flickr Schedulr homepage on CodePlex!

#4 – Proxy Monitor

Last October, the trend continued: another release around a year after the last one. This time, I got the help from David Huntley, who was kind enough to finally get something off my list I’ve been planning to do for a while now: properly setting the proxy via the Win32 API’s instead of just writing to the registry. This more robust way of setting the proxy came for free with the new feature he implemented, which is support for multiple connections. This allows you to specify proxy servers for other connections than the default LAN (such as dial-up or VPN connections).

To make it easier to work together, I decided to move this project to CodePlex as well. So for all information, downloads, forums, etc. go to the new Proxy Monitor homepage at CodePlex!

#5 – The NOT Part

So after a small list of things that I have been up to the last two years or so, it’s quite clear what I have not been up to: blogging. And that’s probably going to stay that way. I either have too little to say (which is increasingly the case), or too much (which would take too much time to write down). So honestly, I expect this would be the last entry on my blog for quite a while – if not eternity.

In case it becomes the latter: thanks for having followed my random thoughts for the last 7 years, and if you want to keep up with what I’m doing on the technical side of life, follow my projects on CodePlex:

• Mayando
• Flickr Schedulr
• Proxy Monitor
• BuildCop
• Configuration Section Designer
• Mollom for .NET

If you want to keep up with the non-technical side, check out my photography site - <plug>based on Mayando of course, and updated with the help of Flickr Schedulr</plug> :-)

Just a quick note to mention a little quirk in Internet Information Services (IIS) I discovered recently: when you have a virtual directory name that ends in a registered file extension, you'll get an HTTP 404 error when browsing to that directory.

We were using http://localhost/MyCompany.MyProject.Svc/MyService.asmx as our web service endpoint, but that kept giving us HTTP 404's. At first, we thought it had to do with the dots in the name (causing us to change our guidelines and drop part of our naming consistency) but I later found out it has to do with the .svc file extension being mapped to the ASP.NET isapi dll. So even though it's clearly a directory name and not a file, we still got the 404.

So we changed our guidelines (once more) to MyCompany.MyProject.Svc.WebServices and all was fine again...

I don't know about you, but I've never been very fond of the new Web Project System in ASP.NET 2.0. I'm sure it has its advantages for some types of users but I've definitely had more than my share of problems with it. Specifically the way that it sometimes (and randomly) starts checking in binaries in Source Control has shortened my life with at least 4 months. Furthermore, having each page compile into its own assembly (by default anyway) and therefore not having a nice place to put assembly-level attributes or define strong naming that work on the entire website has surprised me (in a negative way, that is). What I don't get is that Microsoft had abandoned a familiar and working concept (the Web Application model used in the previous versions of Visual Studio) and replaced it entirely without supporting the old way of working. To me this has always been a major breaking change, and a cause of much frustration.

Well, the pain has now officially ended: the Visual Studio 2005 Web Application Projects has been released, meaning that the old model is back with a vengeance. With a free download from Microsoft, you can get your familiar working environment back in Visual Studio 2005, but with lots and lots of improvements over the previous versions of course (not even mentioning the fact that it's now ASP.NET 2.0 with all its goodness around it).

Some highlights:

• A project file (which I don't consider a feature, more a bugfix over the previous model)! This fixes the problems with the references getting checked in, and lots of other things.
• Because of the project file, you also have pre- and post-build events again (the new Web Project System doesn't support them).
• You can create working Web Setup projects again, containing the content and primary output of the project. With the new Web Project System, you have to download and install a separate update (the Visual Studio 2005 Web Deployment Projects).
• It builds one assembly by default. This fixes the problem with the assembly-level attributes and strong naming.
• The Global.asax file isn't ugly inline script anymore but a proper class in a code-behind file. The "Application_Start" and similar methods are still "magic" though, discovered through reflection I assume, in stead of properly overriding them from the base class or something.
• No more Frontpage Extensions required. Be gone, _vti_*!
• Built-in Development Web Server. Be gone, IIS! Well, not for enterprise scenarios of course, but it's still a very nice feature :-)
• MSBuild support.
• Better web publishing options.
• ...

I've immediately installed and tried it and it works great! One specific detail that I think is a very nice feature (just to show that it's not a quick fix of the old model to run on Visual Studio 2005 but a real full-blown upgrade) is the "Create Virtual Directory" button in the project settings, which allows you to setup a virtual directory in IIS without having to go to the IIS console:

Great!

Anyway, this add-on has made me very happy with ASP.NET 2.0 again. It's the little things that make the difference, but the big things in this case made my day :-)

I was recently looking for a way to unit test a piece of security code that would retrieve the User principal from the current HttpContext in an ASP.NET scenario. Now it was just a plain unit test, not a web test, so I didn't actually have an HttpContext. But how hard could it be to cook one up, right?

So I first tried to set the HttpContext.Current property, but IntelliSense popped up to say: "Gets the HttpContext object for the current HTTP request". So I figure it's a read-only property (because the phrase starts with "Gets...", where read-write properties typically start with "Gets or sets...") and I can't do it directly.

Then I found a post by Steve Maine that seemed to allow setting the current HttpContext by injecting it into the messaging CallContext of .NET Remoting. While that looks like a bit of black magic, I'm never too shy to throw in some snake blood and salamander eyes if it makes my code compile so I tried that, but it didn't seem to work right away. It did, however, provide me with a good way of creating a dummy HttpContext in the first place, which I also needed to do:

SimpleWorkerRequest request = new SimpleWorkerRequest("/dummy", @"c:\inetpub\wwwroot\dummy", "dummy.html", null, new StringWriter());
HttpContext context = new HttpContext(request);

So we just create a dummy worker request that the HttpContext requires and we pass it into the constructor.

Because the black magic wasn't working for me, I looked at the HttpContext class in my favorite .NET tool of all time, and quickly realized that the property was settable anyway ^[1]. So I guess that salamander had a lucky day:

HttpContext.Current = context;

And we're done. A valid current HttpContext for use in unit tests.

[1] Side comment: property documentation that doesn't follow the "Gets..." versus "Gets or sets..." pattern is pretty frustrating. It could have saved me quite some time if the documentation would just say "Gets or sets the HttpContext object for the current HTTP request"...

I've been using the Release Candidate of Visual Studio 2005 lately, and I'm very pleased with the overall look and feel of the application. There are still some issues left to work out (I get the occasional crash and burn), so I hope they'll all be gone by the time they RTM in the week of November 7th...

One of the things I really wished they would have fixed, though, is the way references are handled in ASP.NET 2.0 websites or WebService projects. This is what I had to say about references in June 2004, and it still holds true:

Although certainly not always possible, the ultimate solution to problems with references has always been using Project References. So that's what I'm doing now, but in ASP.NET they tend to switch from project references to fixed binary references that don't get updated anymore. And you wonder why you get runtime errors... So you need to check those references regularly and reset them to project references. Joy! What's even funnier is that an ASP.NET site doesn't have a project file anymore, which would be fine if there was nothing to remember for an ASP.NET project. But what about these references? I'm sorry to have noticed that, but they're stored in the solution file. Bad, bad, bad... If you have multiple solutions with the same ASP.NET project in them, it would depend on the solution file which kind of references the project would use. If you really need project-settings, revive the project file guys and recall the "no project file needed"-hype. What's one file extra going to do anyway?

Apart from the project references randomly becoming binary references (I've seen it happen again in the RC!) I still think it's an even bigger problem that project properties are put into the solution file. If you want proof, this is a part of a solution file that contains a WebService project:

Project("{E24C65DC-7377-472B-9ABA-BC803B73C61A}") = http://localhost/TestWebService/,

"http://localhost/TestWebService", "{F7389224-931A-4652-A0E2-3A932D1B40C6}"

 ProjectSection(WebsiteProperties) = preProject
  ProjectReferences = "{BC53180F-394F-4F31-A61E-BFBC4DBF9B32}|BusinessLayer.dll;"
  Debug.AspNetCompiler.VirtualPath = "/TestWebService"

  Debug.AspNetCompiler.PhysicalPath = "..\..\..\..\POC\TestWebService\"

  Debug.AspNetCompiler.TargetPath = "PrecompiledWeb\TestWebService\"

  Debug.AspNetCompiler.Updateable = "true"

  Debug.AspNetCompiler.ForceOverwrite = "true"

  Debug.AspNetCompiler.FixedNames = "false"

  Debug.AspNetCompiler.Debug = "True"

  Release.AspNetCompiler.VirtualPath = "/TestWebService"

  Release.AspNetCompiler.PhysicalPath = "..\..\..\..\POC\TestWebService\"

  Release.AspNetCompiler.TargetPath = "PrecompiledWeb\TestWebService\"

  Release.AspNetCompiler.Updateable = "true"

  Release.AspNetCompiler.ForceOverwrite = "true"

  Release.AspNetCompiler.FixedNames = "false"

  Release.AspNetCompiler.Debug = "False"

  SlnRelativePath = "..\..\..\..\POC\TestWebService\"

 EndProjectSection

EndProject

The rest of the settings are also project-specific (hence the ProjectSection) so I think it's all unacceptable. But I guess it's too late to change any of this...?

Update: I did some thinking and some of this might actually make sense... As the line in the solution file above actually states, it's a Project Reference. Since project references refer to other projects within the same solution file by definition, this is actually quite logical. I tried to do the same thing with a non-project reference (i.e. a binary reference) and it's not stored in the solution file. But before you start cheering, be aware that the reference isn't stored anywhere at all. The assembly is just copied over to the website and you'll have to update it manually if the reference changed. Not too brilliant either... The fact that project references tend to switch to binary references might have something to do with adding the website to a new solution which doesn't contain the referenced project, but I'm not so sure the reason is that simple.

If you're getting curious HTTP 404 errors in your ASP.NET 2.0 application, be sure to check for a zero-length "magic file" called app_offline.htm and delete that. If this file is present in your web site, then the entire application will be considered offline by the ASP.NET runtime.

While certainly useful as such to quickly disable an entire site, it's not so great that the "magic file" can also "magically appear", especially since there's no indication as to why you're getting the 404, so you can spend quite some time chasing bugs that aren't there. Fortunately, post-beta 2 builds will be providing a proper explanation.

The reason it can appear by itself is that it's used to "take the application offline" when copying a web site. If this operation crashes somewhere in the middle for some reason, the file doesn't get deleted (while we wait for a transactional filesystem anyway) and bite you in your, errr, isapi filter.

Yesterday, David Boschmans blogged about a problem with .NET Remoting and customErrors we noticed at the customer's site earlier this week. It basically boils down to the fact that the customErrors tag in the <system.web> part of the web.config file is being read by the remoting infrastructure (if you're hosting in IIS anyway) to determine whether or not to flow remote exceptions to the caller. I find this very bizarre, as does David. Ingo Rammer left a little note in the comments about the way Indigo will handle this situation, and I'd simply like to add my opinion to the matter here.

I think some confusion lies in the fact that .NET Remoting was designed to be as transparent as possible. I think of it this way: exceptions are part of the contract of a class; .NET Remoting is "only" a means to provide location transparency, so the remoting stack should always ensure that the exception is transferred to the client. There shouldn't even be a setting that influences this, as far as I'm concerned. Especially if that setting lives in the <system.web> section, since I expect that section to only affect ASP.NET sites. Up until now, that wasn't a section I would typically associate with the remoting stack.

The same configuration setting does exist in the <system.runtime.remoting> section as well though, where I can somewhat accept its existance, but certainly not its default value ("remoteOnly") since that can effectively change the behaviour if you scale to multiple servers as David states. That means that if you host your client (e.g. a web app) and server (remoting backend) on the same physical machine, everything will appear to work correctly since the exceptions are transferred locally. If you decide to scale out and move your remoting layer to another server, you'll see an unexpected RemotingException where your own application exception used to be and your app won't work as it used to do (if you're using structured exception handling anyway).

Now, concerning Ingo's comment... Indigo is different. I would actually expect Indigo to have a means to specify the way server-side exception information is exposed, because Indigo was never meant to be transparent - quite the opposite actually: "Boundaries Are Explicit", remember. And with Indigo, you don't typically "trust" the client, whereas with remoting you tend to have a lot more control over the caller so you would allow more trust about the exceptions being transferred. Anyway, I'm looking forward to seeing the new Indigo model in action, and how the [FaultContract] will interact with the various .NET and non-Microsoft clients out there...

I've just expressed my love for comments (which generated some interesting discussion as well) and a while ago I've been quite active in ASP.NET 2.0; so let me take the opportunity to raise a personal concern of mine when combining the two.

Remember that one goal of ASP.NET 2.0 was to reduce the code needed for typical scenarios by 70%. That's a lot and I don't have any metrics yet, but they've certainly managed to eliminate a lot of keypresses that I hope I will never need to break my fingers on again. They've also overhauled the databinding system (just look at the ObjectDataSource) to reduce code and you can even use the Web.config file to declaratively create a strongly-typed Profile, or couple all your pages to a common basepage to include boilerplate code.

So great! With all this, ASPX has definitely become a double-JITted programming language of its own - as Early & Adopter so beautifully put it during the last PDC.

The only problem I have with it, is that when hiding more and more code behind markup, where do we document what we're doing? We don't. Do you? Thought so... So come on, be nice: comment your markup when it gets anywhere near semi-complex.

And don't just write <!-- html comments --> either, but be sure to use the <%-- server-side comments --%> in ASP.NET, since they don't get sent out to the browser (which would increase your final page size and possibly even leak information about your business logic to the browser for everyone to see).

Still, this doesn't do anything to promote itself as metadata (that can be used by tools) like the well-known XML comments, so it's still fairly useless apart from serving as in-line documentation. But then again, if you're writing structured code that needs structured comments, you should really put it in code anyway, and not in markup.

I couldn't wait to upgrade to the new 1.7 version of dasBlog Community Edition (as it's called nowadays) because of all the great new features: far better performance, anti-spam measures, drafts (finally!), and lots more. Three cheers to Omar Shahine, Scott Hanselman, and everybody else who dedicated some precious time to it!

Unfortunately, there seems to be a small bug in the drafts functionality, since posts that aren't marked as Public (i.e. drafts) still show up in the RSS feed. Whoops ;-) I'll be keeping an eye on the bug I submitted to the SourceForge tracker because I really want to start using drafts... Update: My eyes must be deceiving me, the draft version of this post worked perfectly without showing up in the RSS feed... It did fail on my test machine though... Anyway, I'm sure it was my fault then.

If you're planning on upgrading too, you'll notice that you have to run an upgrade tool against your contents directory. The fix for the "Comments may disappear when moving content across GMT timezone boundary" bug I briefly mentioned before and submitted to Omar Shahine may have something to do with that since I believe that triggered the filename changes, sorry about that ;-)

Still, I had a little problem upgrading my content, and I believe it's related to that bug. I pulled the content from my server (which is on time zone GMT-7) to my machine (GMT+2) and ran the upgrade tool. Everything seemed fine on my test machine, but I noticed that the comments on some (what appeared to be) random posts had disappeared. I dug a little deeper and noticed these posts were submitted quite early in the night so I suspected a time zone issue again. I reflectored (uhm, yes, that's a word) the upgrader exe to see what it was doing and I noticed it was using the local time zone for some date-time calculations. So on a hunch I switched my local timezone to the one of my server and everything worked just fine. Whew :-)

So here's a word of advice: if you upgrade your content directory, be sure to temporarily set your local machine to the same time zone as the server the blog will be running on!