Scott Stewart

Strange VSS / VS.Net 2003 behavior

I came across a strange behavior with MS Source Safe and Visual Studio 2003 today; I’m sure it’s a feature and not a bug ;-)

I “got latest” on and opened a solution that contains a number of projects, all of which were “checked-in”. The solution is used by a few developers all working on different parts of it. When I opened things, I noticed that one of the projects had a bad reference. For the most part we are using a “partitioned solution” approach as described in Team Development With Visual Studio .Net and Visual Source Safe. I say for the most part, because we do have a few core components that cross between a few different solutions, which we file reference. Things that you might decide best to put in the GAC during release, but for development purposes we all use a common file reference for now. A pure “partitioned solution” would not have any file references.

When I noticed that one of the projects had a bad file reference (the reference was to another developers local path instead of the common /bin that is being used), I attempted to change the reference to the common location. Later in the day, I got latest on the solution again and noticed that the file reference was back to the old improper location.

If you explicitly “remove” the file reference, you will be prompted to check out the project. You can then add the new correct reference, and when you check all your code back in everything is good. However, if you do not explicitly remove the old reference, and go right to the “add reference” step, and choose to add a file reference to an assembly that is already added (but from a different location), you will not be automatically prompted to check-out the project. The new reference will take place and all will be good for you locally, but Source Safe will not respect the change. The next time a “get latest” is done on the solution…poof, your corrected reference will be gone. You may ask “why would you add the correct reference without removing the incorrect reference first?” Well that’s an easy answer; it’s one less click, and it lets ya do it…or so it appears.

Thanks to Andy Zenker for lending a second set of eyes as we stumbled through what was going on.

You lost me at "hello... no code"

I just got in from attending a local MSDN event. Part of the “Microsoft Across America” series. I came through the door of my house with a new shrink wrapped T-shirt, a dvd with the latest August/September 2004 MSDN stuff, and a slight look of bewilderment on my face.

The August/September topics were 1) Building Custom Controls with ASP.Net, 2) ASP.Net 2.0 Overview and 3) InfoPath with VS.Net. My purpose for going, besides trying to support local MSDN events in my area, was to learn, see and hear more about ASP.Net 2.0. As excited as I am about ASP.Net 2.0 (and all of .Net 2.0 for that matter), I have to admit that I have not even loaded a pre-beta or beta of 2.0 yet, or even opened somebody else’s 2.0 IDE yet. I’m involved with a fairly large .Net 1.1 project that has kept me pretty busy lately. I just don’t have a free machine that I’m either developing or debugging some piece of code that is related to this project in some way or another, and I can’t afford to take the chance or time to cause an unstable situation. So, to compensate I’ve tried to keep up on as much blog, forum, discussions, etc. related to 2.0.

So, as excited, as I was to learn a little more about Asp.Net 2.0, I left the discussion with a look of bewilderment. The reason was the following statement, which was made in the opening comments by the presenter: “…all without writing a single line of code.”

Why is writing code such a bad thing? Why does this continue to be such a holy grail at MSDN events? Here I am, in a room full of developers, at an event that is supposed to be for developers, and once again our goal is not to write a single line of code. Call me old fashioned, call me a dinosaur, but I LIKE TO WRITE CODE. It is what I do for a living, I like to think that I’m pretty good at it, and I like to think that there is value in the code I’m involved with writing.

Don’t get me wrong, I am all for the continued effort to reduce the amount of plumbing and repetitive code that needs to be written. I’m all for drag and drop GUI designers, and automated ways of doing things. And it does looks like we get a lot of new automatic code writing, templates, and even completely integrated web security and configuration management modules all by the click of a button. All really cool stuff.

But, why can’t we write a single line of code. Why can’t we see first hand some of new namespaces and classes. Our presenter, after being persuaded finally opened the code behind (oops, code-beside/partial class, our slides still said code-behind). However, commented that he had absolutely no reason to write any code there. There was nothing he could think of that he would want to do here that he couldn’t do in the designer?

I’m not going to comment on the event location or presenter, because I don’t think it was an isolated thing. I have been hearing the “… all without a line of code” thing for sometime now. I remember the first time I saw a demonstration that involved some dragging of a table onto a designer and finally having rad at my finger tips. I think this was around the vb5 rdo to ado transition period. Ok, it has come a long way since then, and now we are even doing this on web pages. But, from the voice of one developer out there “MSDN - I also want to see some code, it is important to me as a developer.”

FormsAuthentication.UserData - watch its size!

Ok, the first time this bug / misuse of the FormsAuthentication.UserData issue bit me, it cost me wayyyy too much time to get to the bottom of it. It just bit me again, and this time cost me a few hours while I racked my brains to remember what it was that I discovered the last time I fought this in a different application. I remembered there was some truly enlightening thing I found out last time, but couldn’t find notes or comments about it. So now it goes in my blog, and hopefully (if it bites me again a year from now in another application where I may have already included code that could cause it to appear) I will remember that I bloged about it and will save myself a little time.

The problem is that the UserData string of the FormsAuthentication class can only contain about 1200 bytes of data. The problem really has to do with the actual cookie size limit, but it is a sneaky problem.

I don’t think it is documented anywhere in the SDK that the UserData string should not exceed about 1200 bytes. And normally, when you are utilizing the string it is used to persist a user’s roles with the FormsAuthentication ticket. So, when you build the app, you may have a user in a few roles with short names like “admin”, “user”, etc. All is fine. Over time things happen. Other people modify your code, and seeing as UserData is already holding some data, another developer might put more stuff in there. Or overtime, users of the application might create some pretty complex security scenarios with lots of long role names. As silly as it may be to stick that much data in the FormsAuthentication ticket, and I think we all would agree that we would never do that, the point is that you can. And if you do, nothing “blows up”, no exceptions, no real indications that anything is wrong. However, your FormsAuthentication process will stop working properly. Some people will keep getting redirected to a login page because the FormsAuthentication ticket won’t be able to derserialize properly during the authentication process. But no exceptions are thrown!

Conclusion – If you find yourself ever writing data in the FormsAuthentication.UserData string, always, always, always make sure that you add code that prevents this usage from growing into something silly. Because trying to find why some people can no longer login is not very silly.

buildings, factories and trains

A recent blog by Ted Neward has created a little give and take on the hot SOA topic. I couldn’t help but chime in. The topic, and the term's missue are just something that I have gotten pretty passionate about lately.

This is actually a follow up to a comment of a comment of a comment (well you get the picture)…

I have to admit that I am biased towards the “SO(A) = = buzz” (or maybe that is choo choo) side of the camp. Now maybe it’s because I am a small time developer, in a small time city, unaware that the SOA train is going to run me over on the way to building a bigger better Metropolis. However, most of the things I work on building on a daily basis are “factories and buildings”. Some client’s and employers like to market them as Enterprise factories and buildings, but they are still for the most part factories and buildings. The problem is that the SOA buzz leads many developers and architects that I speak with, who are in deed designing factories and buildings, to think they need to drive a train between the offices (or dare I say departments) located in the building. This doesn’t make sense. If my factory or building needs to get some goods from this new railroad turning our cities into Metropolises, then by all means take advantage of that. Similarly, if other factories, buildings, cities, or Metropolises can take advantage of goods you offer, then by all means put them on the train. But, be very careful about trying to drive that train inside your building; because the closest it should come to the factory or building is to the building's “edge”. Maybe someday I will become elected to a City council, and my goal will be to create a bigger better City (hopefully this pays better the building “factories and buildings”). When I’m important enough to be entrusted with a task like that, then creating programs that bring the best of all my buildings and factories together will be very important to my ability to grow my city to a Metropolis

I doubt that Pat will ever see this blog entry. However, if he does I hope it is not taken the wrong way. I love the Metropolis speech. I love reading and learning from all things Pat has to offer. I love thinking about the benefits we can realize by taking advantage of functionality already built by separate autonomous systems, and using that functionality between various platforms. I love thinking about the awesome power and concepts that will be realized in Service Oriented Entripises. I love the things that Web Services (and WSE) are doing for us now and promise to do even more of tomorrow. However, I hate the enormous amount of misguided direction and suggestion that when I am building a factory or building I should be running train track between offices. I will always try to place my buildings and factories, as close to as much train track as possible, so that I don’t get left out of the quickly growing Metropolis. I will get whatever goods I can from the train track (as long as they are cheaper then I can get elsewhere), and I will be more then happy to place goods onto the train when others have needs for my goods. I really don’t think this is too far from the true spirit of SOA. But, for whatever reasons (probably too much luggage) the SOA train is currently getting off track and finding its way deep inside our buildings and factories. choo choo

Compatibility in IE6 for XP sp2

I came across a small bug introduced into one of my applications today due to a change in behavior with IE6 file uploads after installing XP sp2. The application in question allows “forms” of different MIME types to be uploaded to a server (i.e. pdf, word, html) for later processing. I store the MIME ContentType along with the file, and then later use the MIME ContentType within a factory pattern to determine which type of processing object is instantiated to process the document. Previously, when uploading .htm documents to the server, the included MIME ContentType of the posted file would be “text/html”. Now (after XP sp2), the .htm files posted content type is “text/plain”.

Apparently IE was previously “promoting” the uploaded .htm files from text/plain to text/html because it could recognize the html code within the text. IE with XP sp2 will no longer promote files from text/plain to text/html using (something called MIME sniffing).

Anyway, when searching around for the explanation, I came across this document that I thought was a pretty informational read on the compatibility differences with IE6 for XP sp2: http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/XpSp2Compat.asp