In the arely stages I've commented on Microsoft not going the right way, because a major selling point could be that you can run Azure in the cloud or in your own data center. That seemed not to be possible. When Azure almost went live, MS had changed sufficiently to maybe make this possible in the future. With Azure Appliance, this is now definitly a reality.
A recurring theme in web programming is calling a function periodically and/or at a specific date and time. This has two aspects:
Calling a function on a scheduled basis
To be able to call a function on your web app, you first need an endpoint (a URL)
that you can call to kick the function off. In ASP.NET you can do this in several
ways:
With your endpoint in place, you can use the Windows Task Scheduler to invoke the function at any given time and at intervals as low as one minute. With the Windows Task Scheduler you have several options again:
Create a VB Script that calls the URL, as discussed in this blog post by Steve Schofield.
Create a PowerShell script that calls the URL (same as option 1, but more modern).
Have the Windows Task Scheduler open Internet Explorer and open the specified URL (e.g. C:\PROGRA~1\INTERN~1\iexplore.exe -extoff http://www.google.com, which starts IE without extensions). If you do this, you also need to specify that the Task Scheduler closes IE after 1 minute, which you can do in the Settings tab of the task (Windows 2003), or in the Trigger configuration (Windows 2008), as shown below.
Task Settings in Windows 2003
Trigger configuration in Windows 2008
Note: In Windows 2008 the dropdowns governing duration and interval show 30 minutes as lowest value. You can in fact change this to 1 minute by editing the text.
Making sure time-outs don't interfere
A web based call is bound to time-out after a few minutes. If you task takes longer
than that, this may abort the call depending on how you programmed it, and what webserver
settings are used with regards to disconnected clients. To ensure a time-out does
not interfere, you can spawn a new thread and have it call the function. That way
the thread handling the request can return a response to the client, and the function
is carried out regardless. One issue that may arise there is that the function itself
hangs or takes too long. You may want to add logic to ensure that it's aborted after
a certain time, and add logging to notify you of this, and possibly also ensure that
the function can only be run by one caller at a time.
I keep forgetting that I need to use GPEDIT.MSC to configure the Windows Shutdown Event Tracker (which you really don't need in a virtual machine).
Sometimes we come across integration scenario's that look straighforward, but where the devil is in the details. We needed to integrate our asp.net/silverlight application in an existing ASP "classic" site (yes, the still exist). The catch was that we needed to call the ASP "classic" site in a server to server call to get some information, but we needed to do this under the context of the current user. You may be wondering why we didn't go through a shared database or someting, but the problem is that there is little knowledge left of the old app, so changing the existing app was a no go.
So, in order to impersonate the user, you need your server-sided request look like that user. This means forwarding the cookies the user sends, and sending back the cookies the server sends to the user. Below is code that demonstrates that.
HttpWebRequest
webRequestToServer = (HttpWebRequest)HttpWebRequest.Create("http://somedomain/somepage.asp");
webRequestToServer.CookieContainer =new CookieContainer(); foreach (String
cookieKey in Request.Cookies)
{ HttpCookie cookie = Request.Cookies[cookieKey];
Cookie serverCookie =new Cookie(cookie.Name,
cookie.Value, "/", "somedomain");
webRequestToServer.CookieContainer.Add(serverCookie); } HttpWebResponse webResponseFromServer = (HttpWebResponse)webRequestToServer.GetResponse(); foreach (Cookie
serverCookie in webResponseFromServer.Cookies)
{ HttpCookie clientCookie = Response.Cookies[serverCookie.Name]; if (clientCookie
== null)
{ clientCookie =new HttpCookie(serverCookie.Name);
} clientCookie.Value = serverCookie.Value;
clientCookie.Expires = serverCookie.Expires;
Response.Cookies.Add(clientCookie); } webResponseFromServer.Close();
This code works fine in a test environment, but there is a catch... in some cases the domain of the server is not set in the cookie you get on the server side. The problem with that is that when you set the domain, it doesn't correspond to what the server expects. You can see this if you write out the cookies you send/receive (both on the browser connection and te server-server connection) to a log or something (including the domain. It took a while to figure out, but replacing "somedomain" with Request.ServerVariables["LOCAL_ADDR"] did the trick.
An important reason I have a Windows phone is because I have control over which applications I buy and from whom. I decide what I can or cannot install on my phone. With Windows Phone 7 Series Microsoft is blocking this "sideloading", so users can only download and install new software through Marketplace. Basically Microsoft is following the Apple iPhone model with this, and the reason is for this is clear: follow the money. Microsoft has realized that Apple is making millions of dollars from the percentage they get on apps sold through the app store. This is logical, because ultimately it is not your device that makes the difference, but what you can do with it. Functionality and content sell, it's as simple as that.
As I said an important reason for me to have a Windows phone, and not an iPhone, was the control I have over my device. I think I am not alone in this, and I've heard a lot of people using Apple products (iPhone in particular) complain about this too. It's the one thing the makes Apple impopular compared to Microsoft, so I guess Microsoft just wants to be the impopular company. Windows Phone 7 Series will also be impopular to vendors. On that front Microsoft is thightning the screws as well. Microsoft now determines the hardware specs and as vendor you have little options to alter the appearance of the OS. This means there are less options to differentiate yourself from competitors.
I think the new Microsoft policy will ultimately drive people away, rather than gain momentum. It will drive people to Android based phones where phone vendors and users are still in control. If you look at the momentum Android already has, more people will also choose Android over iPhone for the same reasons.
When you're using signing or encryption on your SOAP requests, WCF exepects the response to be signed/encrypted too. When the response is not signed/encrypted the message encoder throws a MessageSecurityException. This is perfectly fine behavior, but in interop scenario's can really bug you, because some WS-* implementations don't sign/encrypt Fault messages. Now, because the message encoder throws the exception, you can't get to the underlying SOAP fault. This means that you have no clue why you received a fault in the first place.
To fix this, Microsoft has provided a hotfix. With this hotfix in place you can specify enableUnsecuredResponse="true" in the binding configuration to allow unsecured responses. Unfortunately this means that also valid responses don't have to be signed/encrypted, defeating the purpose of signing and encryption altogether!
As an alternative, you can implement your own message encoder that wraps the encoder that is actually used. In the wrapper you can either store the received XML for use higher up in the call stack, or retrieve the fault and throw a FaultException<>. Without jumping through hoops the latter option does require your wrapper to know about the fault types it needs to handle. With the former option you can handle the exception higher up in the call stack by catching the MessageSecurityException and throwing a new exception with the XML of the message as a property.
Two months ago I spoke at WDI 2010 in Warsaw, Poland on ASP.NET Web Forms vs. ASP.NET MVC. I should have posted the slides for that session soon after, but just didn't get around to it because of all the work thrown at me. Here they are... finally. Slides (668.34 KB)
Thanks to the great folks organizing the conference. They took great care of me and managed to get a good crowd together. Even though it was a pretty large audience, the level of interaction was very good.
Microsoft has been kind enough to give me the Microsoft Most Valuable Professional Award again. That's the 8th year I can call myself an MVP. Thanks Microsoft for the recognition. As a token of my gratitude I've made some long overdue blog posts :).
If you've ever tried svcutil.exe to import WSDL which has doesn't have <sp:OnlySignEntireHeadersAndBody> specified in the security policy, you'll know that this doens't fly. SvcUtil will tell you the the security policy is not supported. So why is this? I assume this has something to do with the a statement in paragraph 6.6 in the WS-SecurityPolicy specification, which states:
Setting the value of this property to 'true' mitigates against some possible re-writing attacks.
So apparently Microsoft decided that setting it to false is not a good idea, and decided not to support setting it to false (omitting the element).
Talking to a non-WCF webservice is like a box of chocolates... you never know what you're going to get. After solving the issue mentioned in my previous blog post, I had another problem. For some reason the service didn't expect a <wsa:ReplyTo> element if the value was anonymous. Later on the other party adjusted the service so it actually worked as expected from WCF, but in the mean time I did write a message inspector to solve the problem. Besides solving the problem it also is a nice little example of a message inspector.
public
class RemoveAnonymousReplyToMessageInspector
: IClientMessageInspector { privateconststring ReplyToNode ="ReplyTo"; privateconststring WSAddressingNamespace ="http://www.w3.org/2005/08/addressing"; publicvoid AfterReceiveReply(ref System.ServiceModel.Channels.Message
reply, object correlationState)
{} //
Not used for this scenario.publicobject BeforeSendRequest(ref System.ServiceModel.Channels.Message
request, System.ServiceModel.IClientChannel channel) { //
This method is called before the request is sent. You can read/manipulate the message
here. // If you're using signing or encryption, that is done after this, this is the
// unencrypted/unsigned mesage. request = RemoveAnonymousReplyTo(request); returnnull;
} private Message
RemoveAnonymousReplyTo(Message message) { if (message.Headers.ReplyTo.IsAnonymous
== true)
{ int index = message.Headers.FindHeader(ReplyToNode,
WSAddressingNamespace); message.Headers.RemoveAt(index); } return message;
} }
To use this, you'll need to create a class implementing the IEndpoint behavior and add the MessageInspector in ApplyClientBehavior, as follows:
public
void ApplyClientBehavior(ServiceEndpoint
endpoint, ClientRuntime clientRuntime) { RemoveAnonymousReplyToMessageInspector inspector =new RemoveAnonymousReplyToMessageInspector();
clientRuntime.MessageInspectors.Add(inspector); }
Recently I found myself trying to talk to a webservice using signing. It was a WCF calling a Java webservice using a certificate to sign messages. I kept getting the following exception message:
The incoming message was signed with a token which was different from what used to encrypt the body. This was not expected.
After a wild goose chase we finally figured out that the certificate was corrupted. Just installing the certificate again solved the issue.
I've written quite a few functional designs over the years and I've found that for users needing to validate it having visuals is key. In most cases prospective users don't understand what they really get until they see screens. On the opposite side of the spectrum telling developers what to do also is much easier with a screen, especially when you are debating what would be the best and most efficient (coding wise) way to give a user certain functionality. In these situations just getting a piece of paper and draw is the best you can do. The last few years I've done this on and off on my tablet. I can sketch on it, but the results are often so poor to see (and read!), that I can't possible put it in a functional design. This is where a good mockup tool comes in.
A good mockup tool should make you feel like you are drawing, but provide you with predefined controls to make your job fast and easy. Recently I came across Balsamiq Mockups, which is simply jaw dropping. Let's start with the result, which looks pretty much like a hand drawn thing. At first glance that may not seem like a big deal, but it is. It states clearly "This is a mockup, the actual thing may look different". If you give a user something that looks like a screen shot, that is what to expect to get. With this they know it will look differently when it is done, and this also makes it much easier to debate your choices and come up with better ideas (to quote David Platt, "Thy User Is Not You", so they will come up with stuff you didn't even dream about).
Ok, so the result is great, what about getting there? Well, that's a piece of cake, really. Balsamiq is as intuitive a tool as I've seen and I was able to create a pretty complex screen in about 10 minutes. There's a bunch of commonly used controls (and some less common), and you can easily find what you need. Also, you can download tons of additional controls from http://mockupstogo.net. Placing, moving, resizing etc. is all very easy because of the snapping support. Want to see for yourself? Look here.
The last things that I find refreshing is the licensing model and fee. It only costs $79 for a single license, and that comes with updates forever (and they update frequently, so they say). Because the tool is already so good, this means you can use it for years, without having to worry about support or having to get a new version.
This is just a great tool. I am sure I will be using it often.
Just a few days ago Moonlight 2.0 was released. Moonlight is an open source Linux implementation of Silverlight. Moonlight 2.0 should be compatible with Silverlight 2.0, but it also already supports some Silverlight 3.0 features, such as writeable bitmaps, some out-of-browser functionality, and the Silverlight 3 pluggable media pipeline (source: ARS Technica). For us this is very interesting, because we are working on a project involving Silverlight which will run in a public website. The client was worried about the possible reach, and this at least opens the door. According to Microsoft 60% of the PC's in the Netherlands now have Silverlight installed, so this is good news for our client.
Recently we moved our projects to a new TFS server. This means that all workspaces link to the old TFS, and you will get the error message "The path [path] is already mapped in workspace [workspace]" when you try to add a new reference to a project you've already worked on. I keep running into this every once in a while, because we develop from virtual machines and we have different ones for different projects. I also keep forgetting what to do, so this is partly a message to self.
You can solve this by opening the Visual Studio command prompt and typing:
tf workspaces /remove:[projectname]
If you want to remove all of them (which is the case when switching to a new TFS), you can use a wildcard, like this:
tf workspaces /remove:*
Thanks to Gergely Orosz's post on the topic.
I've been reading parts of this book on and off for a long time, and I've pretty much read the whole book and some sections more than once, so it is time for a review (even though this is an "older" book).
If you're a software developer, this is a must read. It gives you a kick in the head about what you should think of when you develop software. The examples David Platt uses in this book are very striking, and will make you think about what you've built yourself. You may feel embarrased sometimes and think "I did that too, shame on me!" However, in the end it will make you a better developer. Platt shows very well that IT is no longer about technology, but about the people operating the technology.
This book is also a fun read. Platt has a good sense of humor, and in some cases the stories he tells themselves are pretty hilarious. The only downside of the book is that at some point repetition kicks in. The message is clear, so you want to move on, but there are still more examples explaining the same thing.
We're doing a project where were talking to non-.NET web services and this means that sometimes we have to see what the exact message looks like. In case you ever need to do this: a MessageInspector will not (always) be suitable for this. This is particularly the case where you're using a certificate to sign the message. Signing happens after the MessageInspector is invoked, so it will just show you the unsigned message. One thing you can do is setup a URL you can post to that logs the incoming message as is. We have a "service" like that available to all developers, because it is a quick and easy solution that doesn't require installing additional tooling or modify code. Another option is to configure message logging (see the MSDN article Recommended Settings for Tracing and Message Logging).