URIs, URLs, and strings
I've been wondering why several methods in the .Net framework accept a
string parameter for a URL. Furthermore, there's that whole URL vs. URI issue.
Here's an article I liked on the URI vs. URL issue:
http://www.bernzilla.com/item.php?id=100
In looking at the .Net framework classes
Uri and
Url, it seems they intend the
Url class to be something special to use in verifying security policy on assemblies. It's part of the
System.Security.Policy namespace. Furthermore, it messes with security permissions, which is a whole topic unto itself in .Net. I decided it makes more sense to use the
Uri class for what I'm doing, even though I'm specifically working with a URL in this siutation. I just didn't like the fact that the
Url class is tied into
System.Security.Policy.
I'm designing some framework classes and want to be careful about the APIs. So, I was wondering why did Microsoft choose a string instead of using the
Uri class in various places in the Framework. While I don't know the answer to that question, I found a great blog from Brad Abrams (lead program manager for the .Net framework). It's a design guideline for using a Uri vs. string.
Here's the blog:
http://weblogs.asp.net/brada/archive/2004/01/12/58031.aspx
Maybe this guideline means we'll see some overloaded methods in the future that accept both a
string and a
Uri. Meanwhile, I'm going ahead and using the
Uri class instead of a
string parameter.
Some things that slowed me down today...
I've been working on a web service and ran into two things that messed me up today. My web service was working fine all along; it was just the code behind doing some things wasn't.
Problem #1: Strong Name Identity Permission
I've been reading a little more about
RUP and have taken some of its recommendations to heart. So, in developing this web service, we're tackling the risky and difficult things first. In this case, it's making sure the web service works properly and can return the necessary information. We're also trying out deployment scenarios
now to make sure we really can deploy and install the thing as we intend. This involves fun with the DNS and Windows Installer (we're using
Wise for the installer).
So, our little web service merely grabs and Xml file and returns it. When it's all done, it will grab stuff from the database, etc. However, for now, the Xml works great. We can work on our bigger risks. Getting the real return stuff out of the database for the web service to return is a triviality.
The basics of the web service were working fine. Now I needed to add encryption. We have some company framework code, and one of the classes takes care of encryption. When I added in this code, the web service stopped working.
This was driving me nuts. Unfortunately, I was trying to debug this with just running the web page that comes up when you go to the .asmx page. It seemed simple enough. But I was now getting errors.
I finally went back to the test app I had written and decided to try communicating with the web service from it. This proved very helpful. Now I got a real exception back from the web service and could see what was wrong: I was getting a security exception. One look at it and I knew what I had forgotten to do. We use
Strong Name Identity Permission on our framework code (I should know; I put most of it there). Well, I had forgotten to add the
AssemblyKeyNameAttribute to the
AssemblyInfo file. Once I put this in the new project, everything worked like it should. I wish I'd solved the problem a little sooner, but the good news is that I solved it!
Problem #2: XmlTextReader
While experimenting with the above, I changed some text in the Xml file that was being returned by the web service. One time I did something that wasn't good Xml. When I used the
XmlTextReader to load it into an
XmlDocument, it threw an exception. Of course, this made it pass over calling the
XmlTextReader.Close() method. This turns out to not be a good thing!
If Close is not called, the operating system will still think that an application is accessing the file, even if the XmlTextReader class goes out of scope and even if the application that called it shuts down! I could not now edit my Xml file to fix the problem I had introduced.
With a quick fix of the code (putting the Close in a finally block), I ran it again and got the error, but at least this time the file was closed so I could now modify it (or delete it). It was a heck of a lot faster than rebooting!
Outsourcing Lessons Learned
I keep meaning to jot down a few things that will hopefully help in future outsourcing projects:
- Make sure the outsourcing contractor documents what has changed in the system (when modifying an existing system in a type of project where we just hand it to them with a spec).
- We need to be prepared to provide acceptance resources to keep things moving.
- Don't forget to have an acceptance plan, too.
- Don't forget to specify the programming language if you care about it. The project they were working on was mostly VB.Net with a little C#. We wanted all new development in C#, but didn't specify that. I'm glad they just happned to pick C# for some new modules.
- Teach the outsourcing people your standards. (Of course, you need to have some first...)
- Ideally, I'd love to have the outsourcing people integrated with our internal processes, such as source control systems, change management, bug tracking, etc.
- If they're doing UI work (either desktop or web), you better talk about graphics. Who's providing them? How will they be provided? What formats? Will they be sliced? If so, how? Etc....
- Be sure to have good test data and scenarios.
- We needed to provide some better techincal specifications. We provided a good functional specification, but could have provided better techincal specifications in areas where we cared about the technical aspects of the solution.
- If we care about performance of the solution, we better discuss that...
Of course, a lot of these things are just a part of good software development practices, anyway (but many organizations don't have a lot of good practices). If you have good practices in place, it's a lot easier to add something like outsourcing. When everything is chaos internally, guess what? that will probably migrate to working with your outsourcing partners, too.
It's important to have a good relationship with your outsourcing partner. Don't be trying to nickel-and-dime things. We had many places where we could have done better, but, thank goodness, we had a good relationship and things went well.
ADO.Net DataSet to ADO Recordset(VB)
We were just talking about doing this at work: using .Net to get recordsets, turn it into XML, and then import it into some old VB code. I figured we could probably do some kindof XSLT to make it happen.
Someone did a little search and came up with an article from Microsoft on how to do this. What a great find:
http://support.microsoft.com/default.aspx?scid=kb;en-us;316337
(previously published under Q316337)
Visual Studio Program Manager Blog
I stumbled across this when Googling today. It's the blog for the Visual Studio program manager:
http://blogs.msdn.com/jledgard/
