While there are a number of quite useful articles about how to access and increment PerformanceCounters through the .NET Framework (the PerformanceCounter class description on MSDN and Creating Custom Performance Counters, also on MSDN to name two), the actual deployment of a web service (or any ASP.NET application, as it turns out) is not so thoroughly covered.
The biggest problem surrounding the move into production of an ASP.NET application that updates performance counters is permissions. By default, in order to increment a performance counter, the user needs to have Administrator or Power User rights. You could change the processModel value in machine.config to System, but that leaves a security hole wide enough to drive an 18-wheeler through. Which is another way of saying “Don't do this!!!!!”.
For completeness, the event log entry that appear as a result of the lack of permissions is as follows:
Event ID: 1000
Access to performance data was denied to ASPNET as attempted from C:\WINNT\Microsoft.NET\Framework\v1.1.4322\aspnet_wp.exe
Also, on the actual call to increment the PerformanceCounter, the following exception is thrown:
System.ComponentModel.Win32Exception: Access is denied
with the stack trace pointing to the GetData method in the PerformanceMonitor class.
As it turns out, the permission set that is required is much smaller than running as “System”. In the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib, set the Access Control List so that the ASPNET user has Full Control. Voila, the problem goes away.
Here are a couple of good tips for making source safe run a little better over the network.
I have seen these before but a client (Mark Comeau) recently reminded me of them.
- Change your VSS Folder for temporary files to be local. It will default to where the VSS Database is installed. Tools->Options...-> General Tab
- Put your ss.ini on your local machine. This file normally is in the \users\ You can move it locally and change the \users.txt file to tell Source Safe where you put it.
Less network chatter means a better response time when using Source Safe over the network.
As much as I don't like to toot my own horn, I'm proud of the fact that I'm now officially published on an MSDN site
. If that isn't worth a “Woo Hoo!!”, I don't know what is.
Overview The IntelliSense in the PDC bits while editing XAML had problems inside Style elements as well as when completing tags and reformatting. This patch addresses those issues to improve the developer experience.
PDC '03 release of Longhorn
PDC '03 release of Visual Studio .NET "Whidbey"
Download: XAML IntelliSence Patch for PDC Visual Studio .NET Whidbey
Next Tuesday (Dec 9th) Object Sharp is hosting a free half day seminar on VS.NET 2.0 (Code Named Whidbey). We'll show a lot of the new features in the IDE like snipits, expansions, snap lines and smart tags. We'll show you new features in C# and VB.NET, also ADO.NET and ASP.NET.
I think you will really enjoy this informal look at the next wave from a developers perspective.
Come on out. It's free and you just might learn something. You can register here.
I haven't written anything in my Blog for quit some time. Mostly because I have been preparing for presentations. We helped Microsoft with their Bigger Better Basic cross Canada tour last month. I spoke in Toronto, Ottawa and Vancouver. It was great. We met lots of wonderful people who were all very excited about Web Services and Client Applications. I'm sure you can tell by the name that the show was for VB developers. My colleagues will tell you it's pretty humorous to say the least that I would wind up speaking to VB developers about how great VB.NET is to develop in.
At one time I would have nothing to do with VB. It was not Object Oriented, that was enough right there. ADO was not great, ASP was not great. It was just too hard to do anything. Well I'm hear to tell you, “VB has come a long way baby“. I was speaking with someone at the show on this very subject. They said “If you told me 1 year ago VB would one day have Generics I wouldn't have believed it”
I still prefer the syntax of C#. In a paste life I was a C developer so I am used the the sparse syntax and I like curly brackets. However, although I still find VB a bit verbose for my taste. I have been developing an application with it and it's a good language, VB.NET has a lot going for it.
If this solution is familiar to experienced XSL users, forgive me. I'm a casual XSL user, so the problem was difficult to identify and I didn't find much in the way of Google entries covering the answer. So that (in my small, secluded little world) makes it blog-worthy.
The situation I found myself in was needing to convert the WSDL output from an ASP.NET page to a specific XML format. The reason for the format is irrelevant. Suffice it to say, that I needed to create a list of the valid SOAP operations for a particular web service. I tool the WSDL that was generated by ASP.NET and started the trial and error process of identifying the correct XSL stylesheet to use. This is where I ran into problems.
I do understand the basics of XPath enough to try simple queries. My starting point was to list out the portTypes for the WSDL. To do this, my initial XPath query was //definitions/portType. This didn't actually return any nodes. I thought this strange, so I dropped down to the more straightforward //definitions. This too returned nothing. Running out of drop-back room, I went with the wildcard //*. Fortunately for what remains of my hair, this worked. So the question of why the other queries didn't work remained.
After more painful attempts (and a weekend to allow my brain some reset), I finally came across the solution. XPath queries don't work with the empty namespace. They require that the namespace be explicit within the query. But the WSDL generated by ASP.NET does not assign a namespace to the WSDL elements, choosing to use the empty namespace. So the XSL file needed to be modified to define a namespace for the URI associated with the WSDL elements. When done, the xsl:stylesheet element looked like the following:
The key here is the xmlns:wsdl attribute. This defines a namespace called wsdl and associates it with the listed URI. This URI needs to match exactly the URI associated with the empty namespace in the WSDL file. And I do mean exactly. Character for character. Byte for byte.
Once this has been added to the stylesheet tag, the XPath queries can be modified to be //wsdl:definitions/wsdl:portType and the results will be as expected.
In order to gain a complete understanding of services-oriented architecture (SOA), one of the basic pieces of knowledge is the structure of a SOAP messages. At a high level, SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. But that description gives short shrift to the true utility of SOAP, that being the transmission of a request for service between two heterogeneous and networked applications. In this article, we look at the structure of a SOAP message in great detail, as well as put the SOAP message into the context of the HTTP request. This second part has to potential to be a fleeting reference, as there is nothing in the SOAP specification that requires that HTTP be the conduit. However the ubiquity of HTTP has made it the de facto standard for transmission and it will probably be a few years before it is displaced.
For the purposes of this document, SOAP is a Remote Procedure Calling protocol that works over HTTP.
The body of the request is in XML. A procedure executes on the server and the value it returns is also formatted in XML.
Procedure parameters and returned values can be scalars, numbers, strings, dates, etc.; and can also be complex record and list structures.
Here's an example of a SOAP request:
POST /examples HTTP/1.1
User-Agent: Radio UserLand/7.0 (WinNT)
Content-Type: text/xml; charset=utf-8
The format of the URI in the first line of the header is not specified. For example, it could be empty, a single slash, if the server is only handling SOAP calls. However, if the server is handling a mix of incoming HTTP requests, we allow the URI to help route the request to the code that handles SOAP requests. (In the example, the URI is /examples, telling the server to route the request to the "examples" responder.)
A User-Agent and Host must be specified.
The Content-Type is text/xml. The charset may be specified, if not, the default is US-ASCII. Other acceptable charsets are UTF-8 and UTF-16. UTF-8 is recommended for maximum interop. See the note on UTF character encodings, below.
The Content-Length may be specified, if it is, it must be correct.
As with the URI in the first line, SOAPAction is used to route the request to a handler on the server that will respond. It's entirely up to the application to determine how this header element is used. In many implementations the URI and the SOAPAction header will have the same value.
The payload is in XML, a single element.
All the attributes of the are required as shown in the example above.
The must contain a single element, which contains a single element which is the procedure call. The name of the procedure is the name of this element. Note that the procedure name must be a valid XML element name.
The elements contained within the procedure call are the parameters to the procedure. The names of the parameters is significant, the order of the parameters are not. Parameter type is indicated by the xsi:type attribute.
For example, the procedure name could be the name of a file containing a script that executes on an incoming request. It could be the name of a cell in a database table. Or it could be a path to a file contained within a hierarchy of folders and files.
A procedure call may take no parameters, if so, the procedure element must not contain sub-elements.
The following scalar value types are supported by this subset of SOAP 1.1.
||32-bit signed integer
||a boolean value, 1 or 0
||string of characters
|xsd:float or xsd:double
||signed floating point number
A value can also be a struct, which is specified by an XML element that contains sub-elements. structs can be nested, and may contain any other type, including an array, described below.
Here's an example of a two-element struct: 18 139
The names of struct elements are significant, the order of the elements is not.Arrays
A value can also be an array, which is specified by an XML element with a SOAP-ENC:arrayType attribute whose value begins with ur-type[, followed by the number of array elements, followed by ].
Here's an example of a four-element array:
The order of array elements is significant, the names of the elements are not.
You can mix types as the example above illustrates.
If the array elements are of a single type, the value of the array element's SOAP-ENC:arrayType specifies the type of the array's sub-elements, for example, SOAP-ENC:arrayType="xsd:int" means an array of four xsd:int elements.
For mixed-type arrays, the SOAP-ENC:arrayType attribute always specifies xsd:ur-type.
For single-type arrays, the xsi:type attribute is optional for array item sub-elements, but its inclusion is recommended.Null values
A value can also be a null, which is specified by an XML element with an attribute, xsi:null, whose value is 1 as follows:
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Date: Wed, 28 Mar 2001 05:05:04 GMT
Server: UserLand Frontier/7.0-WinNT
Unless there's an error, return 200 OK.
The Content-Type is text/xml.
Content-Length may be specified, if it is, it must be correct.
The body of the response is in XML, a single element.
The must contain a single element, which contains a single element which is the returned value of the procedure.
The single element contained in the has an arbitrary name which must match the name of the procedure that was called, with the word "Response" tacked on to the end of its name. Let's call this element the wrapper for the response. Even this is not the actual value of the response, which is contained in the single optional sub-element of the wrapper and must be a valid parameter.
The namespace of the wrapper element should match the namespace in the request.
If the wrapper has no sub-elements then the procedure did not return a value
HTTP/1.1 500 Server Error
Content-Type: text/xml; charset=utf-8
Date: Wed, 28 Mar 2001 05:06:32 GMT
Server: UserLand Frontier/7.0-WinNT
Can't call getStateName because there are too many parameters.
If there's an error return 500 Server Error.
The may contain a which must contain two elements, and .
is intended for use by software to provide an algorithmic mechanism for identifying the fault. is intended to provide a human-readable explanation of the fault.
A may not contain both a and a wrapper (returned value).
When to fault
If you can't process a request, for any reason, you must generate a fault.
Examples of fault conditions include:
1. An element or attribute in a request that is in an XML namespace which has not been declared.
2. A header in the request with a mustUnderstand="1" attribute that you don't understand.
3. A parameter is of a type that you don't support.
I have no problem with the opinion that Steve Gillmor shares both in his original eWeek article or in his subsequent comments in Drew's blog on the topic. Specifically, I appreciate his willingness to stand behind his views. To quote Mr. Gillmor,
“As for Robert Scoble, he is certainly capable of standing behind his own views when he wants to. I certainly stand behind mine.”
I take issue, however, with exactly what he is standing behind. Is it the view that XAML stands for the Transaction Authority Markup Language? Is it the opinion that Longhorn “veers-away” from some unstated (and, to the best of my knowledge, non-existant) standard that separates the layout and logic portions of an application? Could it be that he stands behind the idea that developers create applications using the XSD 'language'? Or that programmers will have to 'unlearn' XSD once Longhorn arrives. If so, it might be better to find a more stable platform on which to make your stand.
The idea that I'm going to have to wait until 2006 before getting access to some of the functionality that will be available in Longhorn is frustrating to me as a developer. Sometimes ignorance can be bliss. But I balance my frustration with the ability to better plan my current application architectures. Do I expect to include XSD/XML functionality in my current code? Certainly, assuming that I want my applications to be able to exchange data with not only other Microsoft products but the rest of the computing world. Do I expect that arrival of Longhorn to change my use of XSD/XML? Only in the integration that my apps have with the file system on which they are running. The rest of the world speaks XML and I don't think that Longhorn will change that significantly. Nor is the release of Longhorn likely to make my life as a developer more difficult, as Mr. Gillmor suggests. If I take advantage of the information that is being made available by Redmond now, I should be ready for it, whenever it gets here.
Along with Sam Gentile and Drew Marsh (and others, I'm sure), I had a chance to read the eWeek opinion piece Can Microsoft's 'Longhorn' Pull it Off?. Is this article an accurate representation of the facts that surround Longhorn? Not even close. Does the article display a lack of understanding by the author of the basic technologies used in Longhorn? Yes. But even if you completely eliminate the chaff, there is still an interesting element that can be gleaned from the approach taken by Mr. Gillmor. What you are seeing is the initial 'shot across the bow' - the angle that Microsoft bashers will take as they attempt to capture mind- and developer-share.
The problem is that, without knowledge that can only be gained by playing with XAML and WinFS or reading articles and documentation on the topic, there is no way for the casual developer to tell the different between eFact and real facts. I guess that means it's time to fire up the old Remington and produce some content more directed to the general masses.