Keith Elder

When .Net 2.0 launched several years ago, WinForm developers got a brand new technology baked into the framework that allowed WinForm applications to be deployed similar to a Web application. The technology was called ClickOnce. ClickOnce has seen a few enhancements since it’s initial release such as the ability to add a desktop icon when an application is installed along with better support for ISVs. One feature still missing from ClickOnce is to make an application start automatically after login. Let’s solve this problem. The Problem When a ClickOnce application is installed the user doesn’t know the directory location it is installed in on their computer. Honestly they shouldn’t care. Not only does the user not know, but the developer doesn’t know either! ClickOnce applications are installed in random directories on each computer in a hidden folder within the user account called the “AppData” folder. For example, here is a screen shot where the ClickOnce version of Witty Twitter that I publish on this site is installed on my newly built machine. As you can see it is in a random place and this is the problem because a ClickOnce application doesn’t have a fixed path like c:\program files\somewhere\myapp.exe. Why? Well, because the ClickOnce team at Microsoft didn’t build in the ability for Developers to specify a location as to where the application is installed, nor can the user select one. The purpose of a ClickOnce app is the end-user clicks a URL that ends in .application and the application installs. Simple, quick, easy. If the application path was set outside of the user’s account it would require escalated permissions. A feature of ClickOnce is it allows the user to install an application without administrative permissions on the computer (great for internal apps at companies for example). Since the ClickOnce apps are installed in the user’s local directory and randomized as to their whereabouts, we can’t place a shortcut URL in the startup folder that points to the executable. Now some of you might be thinking that a Developer can programmatically figure out the location of the executable and place the shortcut in the Startup folder within the menu, thereby allowing the application to start. That would be the wrong thing to do. The reason is ClickOnce applications version themselves as they are installed. If you took this approach, the next time the application was updated, a new version would be installed and the old version still remains. Essentially there are two versions on the machine (this is a feature because it allows end-users to roll back to the previous version if they want to in case the latest version of the application is broke). As you see, creating a shortcut programmatically and placing it in the startup folder on the machine won’t work because it is constantly changing locations. The Solution The solution to the problem is actually really simple. So simple in fact it escapes most. Remember that a ClickOnce application is launched from a URL ending in .application. For example, the Witty Twitter application I publish has a URL like the following: http://keithelder.net/software/witty/witty.application The .application extension is something your computer knows how to process after the .Net framework gets installed. What most developers do is they open up the folder the location where the ClickOnce application installed the shortcut to view the shortcut in notepad. Here’s an example using Witty: If we view the Witty shortcut in Notepad++ it looks like this: The first thing you’ll notice is the extension of this shortcut is different, it ends with .appref-ms. So what happens is developers copy this file to the startup folder, but then it doesn’t work in all cases. It will work on some versions of Windows but not others. Here’s the fix. Right click on your desktop and in the menu create a new shortcut. Next, enter the URL of your application. Here’s a sample using Witty: Click next and give it a name: After saved, open the shortcut in notepad and remove everything but the first two lines. You should have something like this left when you get done: [InternetShortcut] URL=http://keithelder.net/software/witty/witty.application Now you have your shortcut. Wait, that’s just a standard Internet Shortcut? Right! That’s all you need since the application is launched from a URL anyway. You’ll notice after doing this the new shortcut is showing the default browser’s icon (not your application icon), this is perfectly ok. Now that you have your file, simply drag and drop the shortcut into the Startup folder. The next time the computer boots, the application will automatically launch. If you are a developer you are home free now because programmatically writing a file to the user’s Startup folder with this information is simple. In your application you can place a menu option to start the application on startup or not. Their are two downsides using the method I can think of. One, your application shows the default browser’s icon. Secondly, when the computer launches the browser will open for a split second to launch the application but then it closes (at least that’s been our experience).

A reader of my blog sent me an email asking the following question: “I have an XSD that I am required to use to export my company's data. How can I use that XSD and return data to them in a web method? I should be able to return a data set with the information formatted the way the XSD defines but I have no idea how to do that. Any ideas would save me a ton of time and grief!” Turns out this is a really good question, and I think one a lot of developers struggle with primarily because the majority of developers are scared of XSD schemas. Hopefully I can change that. An XML Schema is really simple and it is your friend. What is an XSD or Xml Schema Definition? An XML Schema describes the structure of an XML document. That’s it, see, it isn’t that hard after all! As a developer think of an XSD the same way you would when creating business rules to validate objects before storing them into a database. Some items in objects cannot be null, some can. Some need to have their data formatted (email address for example) and others need to not exceed certain lengths, etc. When dealing with an XML document, we need to apply the same type of rules and this is where the XSD comes in. Once we have an XSD to describe an XML document we can guarantee any XML data we receive conforms to these rules. Ok, enough intro, let’s get coding. The Schema In the case of the reader’s question, an XSD schema already existed. To save time, I’ve taken then general idea of the schema I was sent and slimmed it down for simplicity sakes. The schema represents an XML document that will contain job listings. Here is a view of the schema from the schema explorer in Visual Studio as well as the schema itself (again slimmed down). Once we have a schema defined like this we can generate code to be used for a service. We have a tool at our disposal that is available within the Visual Studio Command Prompt called XSD.exe. This executable does a lot of things but one thing it can do is generate code from an XML Schema Definition. When generating from the XSD file I was sent there was a problem with it. Here is the walk through of that story so you can follow along. When I first tried this on the reader’s original XSD I got an error: Warning: cannot generate classes because no top-level elements with complex type were found. What does this mean? Well, look at the screen shot of the XML Schema Explorer above. Do you see the <> green icons? Well those represent an XML Element. An element is a fancy name for an XML tag like: Bramar Let me roll this up and take another screen shot so you can start to see the problem (i have to hit my magic number of 12 screen shots anyway :) ). See the problem? There isn’t an element in this schema (no green <> thingy). What this means is we have a schema which just lists complex types of elements and enumerations. There isn’t any “xml” in this schema. The fix is simple though. Add an element to the schema. Now we have a green thingy icon which means this XSD contains at least one element. Basically think of the JobListing element as the root element. Now that we have an element we can generate a C# class file from this XSD: The code generated is about 350 lines so I’m not going to include it in the article. There are some nice things happening for us when the C# classes are generated using xsd.exe. For starters the enumerations in the XSD are turned into C# enumerations. The classes are marked serializable and they have the appropriate XML attributes on the properties to serialize these objects into XML. This is a good thing since it means we didn’t have to create it. Code generation is your friend. Now that we have C# objects we can serialize these to XML easily. The Service The first thing we need to do is create the WCF service. For this example I chose to create a WCF Service Application in Visual Studio 2008. After the project is initialized, the first thing we need to do is define the contract for the service. In other words, what is coming in and going back out. Since we have generated our code using the XSD utility we are going to use the XmlSerializer with our service. The reason is this will make sure our XML formatted the way we intended. While we are at it, I’ve made the service a RESTful type of service. Here is the contract. [ServiceContract] public interface IJobService { [OperationContract] [XmlSerializerFormat] [System.ServiceModel.Web.WebGet(UriTemplate="/jobs/{type}", RequestFormat=WebMessageFormat.Xml)] List GetJobListings(string type); } The contract above has one method GetJobListings(). This method has two additional attributes. One, the attribute to mark the method to serialize using the XmlSerializer and two the attribute to turn the method into a RESTful service. In other words our service can be accessed like this: http://localhost/service.svc/jobs/full-time Now that the contract is setup, we just need a class to implement this contract on. Here’s a quick and dirty implementation. public class Service1 : IJobService { #region IJobService Members public List GetJobListings(string type) { return GetJobs(); } private static List GetJobs() { var jobs = new List(); jobs.Add(new Job { JobType= JobType.parttime, Category = JobCategory.Banking, Benefits= "You are on your own.", Description="I did something" }); jobs.Add(new Job { JobType= JobType.fulltime, Category = JobCategory.Banking, Benefits= "You get something." }); jobs.Add(new Job { JobType= JobType.contractor, Category = JobCategory.Banking, Benefits= "Times are tuff, deal with it." }); jobs.Add(new Job { JobType= JobType.fulltime, Category = JobCategory.Banking, Benefits= "How does $700 billion sound?" }); return jobs; } #endregion } Now all we have left is to get this working is to configure WCF to support our RESTful implementation. In order to do this we are going to use the webHttpBinding. Here is the WCF configuration to implement our RESTful service. That’s it, we are all setup. Now all we have to do is launch the service and browse to the URL we outlined earlier to get our results. This may seem like a lot of steps but it really isn’t. I encourage you to take this example and play with it. You can download the solution below. Download Solution WcfService.zip