Check out the ASP.NET Developer center for some changes from ASP.NET Beta 1 to Beta 2. I welcome some of these changes because I was in the croud that logged bugs against Beta 1, and these actions resolve the bugs. The special directory names are changing. Here are the changes:
stays the same
Generated event handlers will be marked as protected instead of private going forward.
The .aspx will no longer be a partial class with the code file and a system file. Instead, the .aspx will inherit from the code file, which will be a partial class with a system file. This solves the problem of not being able to reference UserControl types at design time.
Another great thing, though, is that VWD2005 supports intellisense in the .aspx, so for whipping up code samples for newsgroups or my blog, I can just use a single file. Yeah, I know, I’ve grown lazy and depend on intellisense, but when is the last time you actually got up to change the channel on your TV??? Addicted to the remote control???
Last night, Christoph gave a great talk and demo on Web services and WSE 2.0. I haven’t used WSE yet, so, of course, it seemed like a mystery, but again Microsoft did a great job of making it work with just a few lines of code. WSE deal with the security aspects of web services. Both the client and server have to be using it, though. I found out that if I’m interopping with an older technology using the Soap Toolkit, then I’m stuck with Web Services 1.0 and my own security scheme.
There are plenty of articles out that explaining how to validate Xml, but they all seem to use namespaces or have other factors in them. I didn’t find one that used plain Xml with no namespace declaration, so I whipped up a little example. I included the Xml and Xsd inline and load it using a StringReader, but for your purposes, they would probably be in physical files.
xsd = @”<xs:schema xmlns:xs=””http://www.w3.org/2001/XMLSchema””>
<xs:element name=””name”” type=””xs:string””/>
<xs:element name=””street”” type=””xs:string””/>
<xs:element name=””city”” type=””xs:string””/>
<xs:element name=””country”” type=””xs:string””/>
xml = @”<?xml version=””1.0″”?>
<street>109 Abbey Close</street>
XmlValidatingReader vr = null;
vr = new XmlValidatingReader(new XmlTextReader(new StringReader(xml)));
vr.Schemas.Add(null, new XmlTextReader(new StringReader(xsd)));
vr.ValidationType = ValidationType.Schema;
vr.ValidationEventHandler += new ValidationEventHandler(vr_ValidationEventHandler);
// Validate XML data
Console.WriteLine(“Xml Document is not well-formed.”);
There are a lot of people having issues when they have to change the location of the web service they are calling. Some resort to recompiling the proxy class, but that isn’t necessary. The proxy class that is generated by VS hard-codes the URL of the web service in the class, but with a little foresight, you can avoid problems when the location of the web service changes. First, let’s create a configuration item to control the URL where the web service resides:
<?xml version=”1.0″ encoding=”utf-8″ ?>
<add key=”webServiceUrl” value=”http://localhost/service.asmx” />
Now, we just add 1 line to the code that calls this web service:
myWebService.Batch service = new myWebService.Batch();
service.Url = ConfigurationSettings.AppSettings[“webServiceUrl”];
service.Credentials = System.Net.CredentialCache.DefaultCredentials;
Debug.WriteLine(“Called web service”);
By setting the “Url” property, we can change where the system goes to consume the web service. Now, you can deploy the web service to any server, and if you change your app.config file, your client code won’t miss a beat.
Yesterday afternoon, my web application broke. I have a page that takes a user data file and saves it to the server. I have a web service that takes the contents of a file and does the same thing. A process consumes these files on our development server. I am developing part of it on my machine and dropping the file to the DEV machine for consumption, so I’m creating files on a UNC path. Mysteriously I started getting UnauthorizedAccessException, but my code had been working. I didn’t change anything. I double-checked all the important stuff (identity impersonation, security, etc), and everything was in order. I did the normal research. . . Google groups. For all of you Googlers out there having problems with this exception, I have a solution. Reboot! I checked everything I could think of, and I remembered the rule of thumb that I always tell everyone else: “When in doubt, reboot.” Since I’ve been using Win XP and now 2003 Server as my dev OS, I haven’t had to do much rebooting. My home computer (XP Pro) hasn’t been rebooted in at least two months, and it gets a lot of abuse as well as having umpteen external devices connected to it.
I’m using Windows Server 2003, and it is very stable, and even with the abuse I put it through, this was the first time I’d rebooted this week. It’s a laptop, so I hibernate it. I rarely reboot, but remember that when there is no rational explanation for a problem. . . reboot.