We’ve got openings for customer support engineers! We pride ourselves with excellent customer support located right here in New York City near Grand Central. Work closely with developers in a true software company taking phone calls and helping fortune 100 customers resolve complicated enterprise software issues. Send me a resume to dblock at dblock org if you’re awesome. No recruiters, I mean it.

I am pleased to announce the open-sourcing of WAFFLE.

http://waffle.codeplex.com

WAFFLE stands for Windows Authentication Functional Framework (Light Edition). WAFFLE is a .NET library with a COM interface and a Java bridge that provides a working implementation of server-side Windows authentication, including Forms, Negotiate, NTLM and other SPNEGOs.

The long story:

We had a pickle. Our enterprise application, written in Java, needed Windows Forms authentication. We had no idea how to do this. After logon we wanted to get the logged on user's SID, a fully qualified name and domain groups, including nested ones to match an account in our database. Then we wanted to allow users to switch the application from Forms authentication to Windows authentication with single sign-on. Hard to believe, but we couldn't find anything that did what we wanted! So we wrote WAFFLE. Today we use JAAS and Tomcat and WAFFLE as a back-end, allowing our users to do all of forms logon, Windows NTLM, Negotiate and Kerberos (SPNEGO) authentication. WAFFLE is written in .NET and we use a Jacob Java bridge for interop. In some near future we’ll add the Java code that does Negotiate and NTLM in a Tomcat valve, it’s pretty straightforward.

If nothing else, this code serves as a clean and working example for everything related to LogonUser, InitializeSecurityContext and AcceptSecurityContext APIs.

One of the main reasons I never liked JAVA is because of it's cross-platform philosophy. The idea is that everything needs to be so generic and portable, that you can’t get anything actually done. Running applications in the real world means integrating with the operating system. In my own experience I needed to get the username of the user logged into Windows, so I’ve generated everything from JNI monstrosities, C# libraries with COM wrappers invoked via Jacob to making remote service calls from CXF to WCF. Can someone please provide a solution that doesn’t make me feel retarded debugging SOAP messages for a local call to GetUserNameW?!

Thank you. The answer is called JNA.

Wrapping a Win32 function is a trivial exercise for any C/C++ developer who dealt with Win32. GetUserNameW takes a wchar_t buffer and a pointer to a length. In JNA this looks like this.

In order not to feel too much like a Win32 developer, we ought to wrap this thing with a usable method. GetUserName returns a boolean for success or failure and can give us an additional error when the buffer isn’t sufficiently large.

Note how JNA implements those nice methods that convert char[] buffers to String. That’s service!

I’ve been tracking a bug in CabLib, used in dotNetInstaller recently. CabLib is a complete C# and C++ wrapper for Cabinet.dll and its goal is to make it easier to CAB files. Anyone who used Cabinet.dll’s interface directly will quickly discover that it follows the usual Microsoft Win32 mantra: if a developer can do something himself with the existing API, don’t include that functionality in the platform SDK. This produces a well thought-through Cabinet SDK, provided that your user has a major in computer science and a PhD in cognitive psychology.

One of the more interesting aspects of CABs is so-called split CABs. This is just a chain of CAB files, useful if you need to put CABs on a set of floppy drives or embed as a Win32 resource, as dotNetInstaller does (resource size is limited). The Cabinet.dll interface is based on callbacks: you call FDICopy and it calls you back (fdintCABINET_INFO) whenever it encounters a file that is split over several CABs, telling you which next CAB to process. Logically, you would want to process that next CAB, except that here you need to wait for FDICopy to return to do it. This means you need to remember what the next CAB name is, so that you can call FDICopy on it. The algorithm around FDICopy looks like this.

… and the callback …

There’s a bug here, one that was not obvious to track. The symptom is that you’re not getting all the files extracted, some CAB files are missed. The problem is that while you’re processing CAB1, for FILE1 you can get a callback that says to continue in CAB2. Then you can get a callback for FILE2 that says to continue in CAB3. You should be ignoring that second callback because you haven’t processed CAB2 yet.

I initially fixed it with a list, but CabLib author pointed out that this is an overkill. The final code looks like this.

This was a huge time suck from my development time. If there’s one conclusion you want to take away from this, is that you should never design an interface like the one in Cabinet.dll.

I was very happy upgrading to Windows 7. Virtually everything worked. All kinds of source code that I am writing compiles and runs without issues. It’s only a week later that I had to touch the AppSecInc. Community MSI extensions and discovered that most unit tests are failing. I talked about unit testing custom actions earlier. I finally got to the bottom of it.

On Windows 7 the behavior of MSIOpenPackage has changed. We use it to run unit tests by creating a database (MSICreateDatabase) and calling MSIOpenPackage to get a working handle. On Windows 7 code that worked earlier always returns 0x80070645: This action is only valid for products that are currently installed. This is one obscure error code! Why do I need an installed product to open an MSI package?

Microsoft.public.platformsdk.msi was helpful [thread]. For MsiOpenPackage to succeed you now have to have a Property table with a populated ProductCode value in the MSI file itself. MsiExt shim code now looks like this. The two Execute statements are new. This incidentally demonstrates what fields you need in the MSI summary to get a valid MSI.

Hope this saves you hours of fruitless debugging.

Maybe Raymond can answer why this change in behavior in Windows 7?

All VMWare VixCOM users eventually go through a moment of being puzzled with the behavior of VixCOM ReadVariable function used with VIX_GUEST_ENVIRONMENT_VARIABLE (read this thread). This is supposed to return values for the guest OS environment variables. You can get the value for %TMP%, but not for %ProgramFiles%. It’s probably due to the fact that VMWareTools aren’t really creating a user environment after login, but who cares, that renders the function virtually useless.

Can we work around it?

Now that we know how to pipe output, we can just run “set”, collect and parse the results.

Implemented as Vestris.VMWareLib.Tools.Windows.Shell.GetEnvironmentVariables(). It’s a method rather than a property because it actually executes remote commands and environment variables change over time.

Problem solved.

This is a pretty common question on the VixCOM forum: How do I run a command in the virtual machine and collect its output?

VixCOM doesn’t have any support for this, so is there something we can do about it? I want to have a RunCommandInGuest to execute shell and other commands that returns StdOut and StdErr. So this is what I want to write:

I figured that the easiest way would be to pipe output to a file and collect that file. Because the commands can also contain piping, we have to create a temporary .bat that contains the command. I did it for Windows, so you get Vestris.VMWareLib.Tools.Windows.Shell.RunCommandInGuest in VMWareTasks.

Problem solved.

dotNetInstaller 1.8 was released today, January 24th, 2010. Build 1.8.7120.0 has been beta, then a release candidate for over a month now with no major issues reported. Here’re some highlights.

• Added support for uninstall sequences with new command-line /i and /x switches, supportsinstall, supportsuninstall global options in configurations, components and controls. Added extended uninstall parameters in cmd and msi components.
• Added user-defined form controls and input for labels, checkboxes, edit boxes, hyperlinks and file/directory browse controls.
• Added user-defined splash screen embedded with the InstallerLinker /Splash option and an optional /nosplash switch to dotNetInstaller.
• Added returncodes that specify which return code(s) should be treated as success, failure or a required reboot.
• Added support for a license agreement checkbox user-defined control.
• Added clear_cache to download components. When true, attempts to clear the local internet cache entry for the url to download.
• Cabbing now embeds files that belong in components in separate resource streams, extracting only those files that are necessary for installation of a particular component. Embedded files outside of components continue to always be extracted.
• CAB extraction uses the memory-mapped resource streams and no longer writes temporary files to extract embedded components. This significantly reduces disk space requirements and improves extraction speed.

dotNetInstaller continues being the most widely used setup bootstrapper. Please reply to this thread if you’re using it too.

Someone kindly reported a bug entitled “Times Rounding Off” on FoodCandy.com.

“I just created a new event, scheduled to start at 6:30 PM on December 14th. When it displays, it shows a start time of 6:00 PM. If I edit it, it shows 6:30 PM.”

I tried to reproduce at no avail. After-all, it’s not that complicated to display a time correctly, especially when it’s the same one as the user enters. How could I have possibly introduced a bug in something this simple? Could this be a user error? So to nail this down, I got a recording of what the user sees.

Looks like a MAC. That’s the problem! It’s a conspiracy of Apple against Microsoft. There must be code in Safari that changes 6:30 to 6:00 every time it hits a website written in .NET.

The screenshots are convincing. The problem exists. And the cause is right there on the screen. The browser' time zone is Adelaide (GMT+09:30). Adelaide, turns out, is the capital of South Australia and has a population of just over a million people. It has a superb climate and cheap housing. It also has a time zone that is nine and a half hours away from UTC. Nine and a half? That’s weird, I’ve never paid attention to half-hour time zones. Turns out there’re others, including Kathmandu, GMT+5:45. Debugging the code it was clear that my entire time-zone system was rounding hours. And now I remember why.

When I started dealing with time zones, I added code that let the user choose which time zone he’s in and defaulted the value to the browser time zone. The latter comes from a browser cookie, x-VisitorTimeZoneOffset. I wrongly assumed that the offset is an int, so it did int.Parse. That was the first mistake because in Adelaide the browser time zone would be +9.5. I wanted this value to become a TimeSpan, but this is not serializable,  hence all methods that needed the user’s time zone offset took an int. Adelaide time zone offset would be 9 and all the times, stored in UTC and converted to the user’s time zone were wrong by 30 minutes.

In order to fix this I had to make a few changes.

1. Fix TimeZoneInformation.cs to return TimeSpan instead of an int for UTC bias and to parse the browser time zone offset as a float. TimeZoneInformation is, btw, a very helpful class that originated here and is capable of enumerating system time zones and do the time zone math taking care of daylight savings and stuff like that.
2. Change all native methods that took an int UTC bias to take a TimeSpan.
3. Change all SOAP methods that took an int UTC bias to take a long UTC bias in ticks. This makes it serializable and I can new TimeSpan(ticks) on the server or client side.
4. Change the code that adjusts UTC times to Add a TimeSpan and not AddHours a UTC bias.
5. Write some unit tests for TimeZoneInformation.

And finally, ask someone in Adelaide to test this for me.

In a previous post I had implemented clicking through menus with White. Someone pointed out that this was a solved problem and I didn’t need to write any code.

What I noticed next is that it would take anywhere from 3 to 10 seconds to resolve mainWindow.MenuBar. I looked at the implementation and it does a descendents (DFS?) search. The menu bar is a child of the window, so we can avoid the recursion altogether.

Generalizing this further, a simple tree walker with a depth limit seems to be much more efficient for both scenarios of deep and wide trees. The following code comes from this thread, I didn’t write it.

The new test code executes magnitudes faster to click File –> Save.

Another interesting aspect of this menu bar is that it is virtualized. This means that while you may be holding an instance of a MenuBar, it may have been hidden by another UI element at some point and will now throw an exception with the UIA_E_ELEMENTNOTAVAILABLE error code if you try to use it. This is annoying: if I need to click on 10 menu items, I have to do 10 searches, starting from the top every time! To solve this, .NET 4.0 has introduced a new IUIAutomationVirtualizedItemPattern that has a Realize method to materialize the object again.

I feel like I live in this presentation by Mary Poppendieck: The Tyranny of the Plan.

Just when I thought things were well under control in dotNetInstaller, someone filed this bug. It basically says that an installed check doesn’t work. This is pretty major functionality and I was under the impression that I unit-tested it in every possible direction. There’s at least a dozen tests that walk all kinds of scenarios around these checks and everything passes. It took ten seconds to find the culprit: the UI has a silly bug and such a check cannot be added to a configuration node. Naturally unit tests don’t use the UI. The user cannot take advantage of the functionality, even though the functionality itself … functions.

It’s a great example of total failure. Something has to be done.

Executing the Application

The first part of testing a UI is being able to execute and shutdown the application. Fortunately .NET has a very usable model for this.

Simple UI Tests

We can fetch the window title and test simple scenarios such as passing /? on the command line: the window title should be “Help”.

Hitting Menu Items

Getting the window title is nice, but I want to click through menus, or drag and drop stuff! After a bit of search I stumbled on the Microsoft UI Automation Framework in .NET 3.0. I had it running in half an hour and I am impressed. I’ll agree with James McCaffrey who writes in this post “I believe the development of the UI Automation library is one of the most important advances in test automation to date” and John Robbins who says in his article that this is the “realization of the dream of being able to automate the GUI portions of your application plus the guarantee that the playback would be exactly what you expected”. We’ve been doing this for web applications for ever, now this kind of robustness comes to Win32 forms and WPF applications.

I used these two articles to get started, so I’ll skip the how. Just read them.

• GUI Control to Major Tom (John Robbins)
• The Microsoft UI Automation Library (Dr. James McCaffrey)

Dumping Controls

I was too lazy to look at the code of the application I am testing, so I wrote something simple to dump controls. This gives a tree of controls that I can now fetch, use, etc.

Working with Menus

You can locate the application’s menu bar and each menu.

To click the File menu, you get a pattern that applies to menus and call a specific pattern method (for an ExpandCollapsePattern, Expand).

You can already see that this is becoming rather cumbersome. I would have to write a UIMenu and UIMenuItem class or it’s going to be a copy-paste exercise.

Project White

Someone must have had this problem before me. That someone is ThoughtWorks and they created White. White exposes a strongly typed and therefore less verbose and more usable object model for the UI being tested.

Clicking Through Menus

Clicking through menus with White, starting with the top-level application menu, could use a helper function. Each item needs to be clicked in order to fetch its children, collapsed menu items don’t have any.

Here’s how to use it:

Bug Solved and Unit-Tested

My original problem was a bug in dotNetInstaller where adding an installed check through the UI would popup an error. I was now able to write a unit test for it, see it’s source code.

I think this is a great extension of the classic “This is not a bug, it’s a feature” - “This is not a bug, it’s misaligned customer expectations.” by Kevlin Henney from this presentation.

We’ve recently upgraded the Visual Studio 2005 SP1 C++ Redistributable to a newer version with the ATL security update. We quickly found that the installer requires a reboot in about half of our upgrade scenarios. This is understandable because our own application is running and using the CRT and while the ATL security update looks like a new side-by-side installation magic happens that involves the previous version.

Interestingly in a few spot tests the installers finished successfully without the reboot, even after prompting for one. Since a CRT is available already, almost all DLLs can load and run just fine with the current version – some SxS manifest points the CRT to the latest version installed. We decided to be clever and suppressed the reboot by telling dotNetInstaller to ignore the 3010 return code and by installing the CRT redistributable with /q:a /c:”vcredi~3.exe /q:a /c:””msiexec /i vcredist.msi /qb!””” (if you just run vcredist_x86.exe /Q you get a reboot prompt). Once checked into source control, built and in automation, 4 out of 27 daily install/upgrade scenarios failed. The culprit was some C++ DLL that failed to register.

This was all a bad idea: we’re constantly making extra effort to avoid reboots for our customers, but we forget that reboots exist for a reason and that people upgrade a production system every six months with careful planning for downtime and even rollback. A reboot is not that bad. Everyone should stop suppressing reboots, an obscure DLL registration failure for 4 out of 27 customers is much worse than a required reboot for half of them.

Once reboot was back in-place, our RemoteInstall automation broke. We run the entire bootstrapper with /q, which forces a silent install that reboots in the middle. RemoteInstall doesn’t know how to handle this and thinks that the server vanished in the middle of installation. It fails the test.

Nothing that 10 minutes of coding can’t solve.

Rather than trying to make RemoteInstall understand that the installer forced a server reboot, we want it to take control of the reboot process. The first step is to split the bootstrapper installation into the Visual Studio CRT installation and our application, “pre-install” the CRT. If the CRT requires a reboot (return code 3010), RemoteInstall will shutdown the guest operating system and power it back up (reboot is not directly supported in VMWare VIX). It can then continue with the next installer. I implemented this behavior in RemoteInstall 1.2 Beta, including an additional rebootIfRequired option for those picky developers that don’t believe me when I say you should stop suppressing reboots.

This is what the new configuration looks like for executable setups. The list of exit codes says to reboot on 3010, succeed on 0 and fail otherwise. MSI setups do this automatically since 3010 is a documented MSI return code that signals reboot.

This is what the output from a run in CruiseControl looks like. You can see the messages about a required reboot.

I’ve been wanting to implement a POST protocol for my blog for a while. The urge got really bad since I’ve started using LiveWriter at my day job. It’s such a nice piece of software compared to blogging with the online HTML editor with it’s, often too smart, HTML cleanup, struggling with embedded pictures and loosing drafts. I even considered abandoning my own creation and using WordPress or some other blogging engine. Then the “not invented here” syndrome took over. I spent a few hours implementing a large part of AtomPUB, RFC-5023.

The Atom Publishing Protocol is an application-level protocol for publishing and editing web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format, RFC-4287.

Generating Atom Feeds

My current blog implementation supports ATOM. This is done by using an asp:Repeater to which I bind a data set.

1. <feed xml:lang="en-us" version="0.3" xmlns="http://purl.org/atom/ns#">
2. <title>Title</title>
3. <link rel="alternate" type="application/xhtml+xml" href="AtomPost.aspx" />
4. <asp:Repeater id="repeater" runat="server">
5.    <ItemTemplate>
6.     <entry>
7.      <idPost/<%# Eval("Id") %></id>
8.      <title><%# Renderer.Render(Eval("Title")) %></title>
9.      <created><%# ((DateTime) Eval("Created")).ToString("s") %> GMT</created>
10.      <modified><%# ((DateTime) Eval("Modified")).ToString("s") %> GMT</modified>
11.      <issued><%# ((DateTime) Eval("Created")).ToString("s") %> GMT</issued>
12.      <author>
13.       <name>author</name>
14.      </author>
15.      <content type="text/html" mode="xhtml">
16.       <body xmlns="http://www.w3.org/1999/xhtml">
17.        <![CDATA[
18.         <%# Eval("Body") %>
19.        ]]>
20.       </body>
21.      </content>
22.      <link rel="alternate" type="text/html" href='ShowPost.aspx?Id=<%# Eval("Id") %>' />
23.      <link rel="edit" href='AtomPost.aspx?Id=<%# Eval("Id") %>' />
24.     </entry>
25.    </ItemTemplate>
26.   </asp:Repeater>    
27. </feed>

This works fine for generating feeds, but in order to consume ATOM posts I will need an object model for feed items. That’s where the “not invented here” syndrome has to stop and I am going to let Argotic do the job. First, by rewriting the above ASP.NET code in C# (AtomPost.aspx).

1. Response.ContentType = "application/atom+xml;charset=\"utf-8\"";
2.  
3. AtomFeed feed = new AtomFeed();
4. feed.Title = new AtomTextConstruct(Title);
5.  
6. List<Post> posts = SessionManager.BlogService.GetPosts();
7.  
8. foreach (TransitPost post in posts)
9. {
10.     AtomEntry atomEntry = new AtomEntry();
11.     atomEntry.Title = new AtomTextConstruct(post.Title);
12.     foreach (TransitTopic topic in post.Topics)
13.     {
14.         atomEntry.Categories.Add(new AtomCategory(topic.Name));
15.     }
16.     atomEntry.Content = new AtomContent(post.Body, "html");
17.     atomEntry.PublishedOn = post.Created;
18.     atomEntry.UpdatedOn = post.Modified;
19.     atomEntry.Id = new AtomId(new Uri(string.Format("{0}Post/{1}",
20.         SessionManager.WebsiteUrl, post.Id)));
21.     atomEntry.Links.Add(new AtomLink(new Uri(string.Format("{0}AtomBlog.aspx?id={1}",
22.         SessionManager.WebsiteUrl, post.Id)), "edit"));
23.     AtomLink atomEntryUri = new AtomLink(new Uri(string.Format("{0}ShowPost.aspx?id={1}",
24.         SessionManager.WebsiteUrl, post.Id)), "alternate");
25.     atomEntryUri.ContentType = "text/html";
26.     atomEntry.Links.Add(atomEntryUri);
27.     feed.AddEntry(atomEntry);
28. }
29.  
30. feed.Save(Response.OutputStream);
31. Response.End();

AtomPub Discovery

A client that creates posts must be able to find out where to POST to. This is done by creating a service document and pointing the default blog page to it. Interestingly LiveWriter is a little thick with relative URLs, the href below is actually replaced by full URI in code.

1. <link id="linkAtomPost" runat="server" rel="service" type="application/atomsvc+xml" href="AtomSvc.aspx">

The service document describes a workspace with collections. We have two: one for posts and another for images. The one for posts includes post categories.

1. <service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom">
2.   <workspace>
3.     <atom:title>DBlog.NET</atom:title>
4.     <collection href="http://LoCaLHoST/DBloG/AtomPost.aspx">
5.       <atom:title>Posts</atom:title>
6.       <accept>application/atom+xml;type=entry</accept>
7.       <categories>
8.         <atom:category term="category1" />
9.         <atom:category term="category2" />
10.       </categories>
11.     </collection>
12.     <collection href="http://LoCaLHoST/DBloG/AtomImage.aspx">
13.       <atom:title>Images</atom:title>
14.       <accept>image/jpeg</accept>
15.       <accept>image/gif</accept>
16.       <accept>image/png</accept>
17.     </collection>
18.   </workspace>
19. </service>

We now have Default.aspx that points to the service document, which points to AtomPost.aspx that can generate a feed. The rest doesn’t exist yet, but this is enough to make LiveWriter happy and allow it to register the blog. LiveWriter will automatically detect the Posts collection and, since it’s still a little thick, prompt to which image collection to post images to (we only have one).

Creating Posts

To create a post we must at least understand a POST request to AtomPost.aspx.

The client is posting an ATOM entry that we must read.

1. AtomEntry atomEntry = new AtomEntry();
2. atomEntry.Load(Request.InputStream);

The blog system has objects of type Post that are going to be created. Also note that the post comes with ATOM categories – here you would need to recognize which ones must be created and which ones exist as well as associate the categories with the new post. We’ll omit that code to simplify things.

1. Post post = new Post();
2. post.Id = RequestId;
3. post.Title = atomEntry.Title.Content;
4. post.Body = atomEntry.Content.Content;
5. post.Created = atomEntry.PublishedOn;
6. post.Modified = atomEntry.UpdatedOn;
7. post.Id = SessionManager.BlogService.CreateOrUpdatePost(post);

The post has been created, the server must respond with 201 Created and a new location for this post.

1. Response.ContentType = "application/atom+xml;type=entry;charset=\"utf-8\"";
2. Response.StatusCode = 201;
3. Response.StatusDescription = "Created";
4. string location = string.Format("AtomPost.aspx?id={0}", post.Id);
5. Response.Headers.Add("Location", location);
6. Response.Headers.Add("Content-Location", location);

We’ll also add metadata that describes the new post ID and location and return the post to the client.

1. atomEntry.Id = new AtomId(new Uri(string.Format("Post/{0}", post.Id)));
2. atomEntry.Links.Add(new AtomLink(new Uri(string.Format("AtomPost.aspx?id={0}", post.Id))));
3. atomEntry.Links.Add(new AtomLink(new Uri(string.Format("AtomPost.aspx?id={0}", post.Id)), "edit"));
4. AtomLink atomEntryUri = new AtomLink(new Uri(string.Format("ShowPost.aspx?id={0}", post.Id)), "alternate");
5. atomEntryUri.ContentType = "text/html";
6. atomEntry.Links.Add(atomEntryUri);
7. atomEntry.Save(Response.OutputStream);

There’s no more data to be written to the client. Note that this throws a ThreadAbortException that must be trapped in the page code.

1. Response.End();

Updating and Retrieving Posts

There’re actually four scenarios to implement in AtomPost.

• GET: retrieve all posts – see Generating Atom Feeds code above.
• GET with a post ID: retrieve a specific post - a subset of GET for all posts.
• POST: create a post – see Creating Posts code above.
• PUT with a post ID: update an existing post – see Creating Posts code above.

1. switch (Request.HttpMethod)
2. {
3.     case "POST":
4.     case "PUT":
5.         CreateOrUpdatePost(sender, e);
6.         break;
7.     case "GET":
8.         if (RequestId > 0)
9.         {
10.             GetPost(sender, e);
11.         }
12.         else
13.         {
14.             GetPosts(sender, e);
15.         }
16.         break;
17.     default:
18.         throw new NotSupportedException(Request.HttpMethod);
19. }

You can see the complete code for AtomPost here.

Creating Images

Images are similar to posts, except that image data is never embedded in an Atom entry. An image is simply POSTed as binary data and reused in posts with the location that the server returns.

1. Image image = new Image();
2. image.Id = RequestId;
3. image.Name = string.Format("{0}.jpg", Request.Headers["Slug"]);
4. image.Data = new byte[Request.InputStream.Length];
5. Request.InputStream.Read(image.Data, 0, (int)Request.InputStream.Length);
6.  
7. image.Id = SessionManager.BlogService.CreateOrUpdateImage(SessionManager.Ticket, image);
8.  
9. Response.ContentType = "application/atom+xml;type=entry;charset=\"utf-8\"";
10. Response.StatusCode = 201;
11. Response.StatusDescription = "Created";
12. string location = string.Format("AtomImage.aspx?id={0}", image.Id);
13. Response.Headers.Add("Location", location);
14.  
15. AtomEntry atomEntry = GetImage(image);
16. atomEntry.Save(Response.OutputStream);
17. Response.End();

Similarly to AtomPost, AtomImage supports GET, POST and PUT. You can see the full code here.

Security

All the POST and PUT calls must be authenticated, but I will leave this exercise to your particular system. I use form-based authentication, so I got lazy and did basic authentication in code – it should move out to an authentication provider so that the blog system supports both form-based and basic auth.

Conclusion

This was pretty easy after-all. It took less time putting this code together than struggling with the HTML editor in the past. And I am now writing this in LiveWriter!

Customer: I want a product that does X.
Developer: Done.
Customer: Already? But there's no icon!
Developer: Bug! Here's the icon.
Customer: I click on an icon, nothing happens.
Developer: Bug! It now popups a window.
Customer: But I don't see customer records in this window!
Developer: Bug! ...

• We made every single developer care about installation and everyone learned through brown bags how to write an installer or what Windows installer is about and why it's harder than it seems.


• We changed technology to Wix so that we can share the work load across the organization and so that every developer adding a file makes sure to take care of the installer at the same time. We made installer code just like C++, C# or Java code.


• We re-thought individual installable components from scratch and how they assemble into a working product. We wrote brand new merge modules and MSI installers.


• We developed C++ custom actions (DTF didn't exist in the public then to write managed ones) and Wix extensions that not available in wix and that are now open-sourced as AppSecInc. MSI Extensions. We evolved a unit-test system from an MSI shim to using the MSI engine for every single CA to make sure they are robust.


• We re-thought suite deployment and settled on dotNetInstaller bootstrapper to chain the whole thing together, contributing some features as well.


• We invested into test automation with the RemoteInstall Test Framework to cover the hundreds of install and upgrade scenarios.

RemoteInstall Test Framework

AppSecInc. MSI Extensions

AppSecInc. MSI Extensions

Application Security Inc.

• System Tools: deals with copying, moving, deleting files out of sequence, compare versions, execute commands, process template files, copy registry keys, etc.


• Java Tools: deals with jar and unjar.


• Data Sources: deals with generic ODBC and specific MSAccess and MSSQL databases, SQL files, etc.


• User Privileges: deals with local users and groups.


• Common UI: dialogs for installing Windows services and databases with credentials.

• Manipulating files, folders, registry, services.


• String template and regex processing.


• Active Directory functions.


• ODBC and DMO functions.


• Local users, groups, security and privileges.


• Encryption, decryption, signing.


• Xml file manipulation.


• TcpIp functions.

• Supports impersonation in all custom actions.