A while ago I got a call from a customer who wanted to understand what is the meaning of the version number’s in a compiled assembly and more than that, he wanted to understand how they are calculated. He expected that at least the build number were incremented every time a build is done, but that was not always happening… As I guess you know, what that customer was talking about are the Major Version, Minor Version, Build, Revision (see Assembly versioning). This version number is physically represented as a four-part string with the following format: <major version>.<minor version>.<build number>.<revision>. For example, version 1.5.1254.15632 indicates 1 as the major version, 5 as the minor version, 1254 as the build number, and 15632 as the revision number. The version number is stored in the assembly manifest along with other identity information, including the assembly name and public key, as well as information on relationships and identities of other assemblies connected with the application. Of course you can manually specify the assembly version you want to use by setting it in the AssemblyInfo.* file, but if you leave to Visual Studio the task to calculate it, here is what happens (as usual…
-
-
aspnet_wp.exe can not be started. Code: 80070003
This was a Windows 2000 server with ASP.NET 1.1 installed, and for some reason the customer was unable to start his web applications, he was getting "Server Application Unavailable" messages on the client. We found the Application event log full of entries like this one: Event Type: Error Event Source: ASP.NET 1.1.4322.0 Event Category: None Event ID: 1084 Date: 18/02/2008 Time: 15.59.43 User: N/A Computer: <computername> Description: aspnet_wp.exe could not be started. The error code for the failure is 80070003. This error can be caused when the worker process account has insufficient rights to read the .NET Framework files. Please ensure that the .NET Framework is correctly installed and that the ACLs on the installation directory allow access to the configured account. The next logical step is to use Process Monitor to try to spot any "Access denied" errors, but there weren’t. Interestingly within the procmon trace we instead found quite a few entries similar to the following inetinfo.exe:1112 OPEN C:\Debuggers\cdb.exe PATH NOT FOUND inetinfo.exe:1112 QUERY INFORMATION C:\Debuggers\cdb.exe -server PATH NOT FOUND inetinfo.exe:1112 QUERY INFORMATION C:\Debuggers\cdb.exe -server.exe PATH NOT FOUND inetinfo.exe:1112 OPEN C:\Debuggers\cdb.exe -server PATH NOT FOUND inetinfo.exe:1112 QUERY INFORMATION C:\Debuggers\cdb.exe -server tcp:port=8090 PATH NOT FOUND inetinfo.exe:1112 QUERY INFORMATION C:\Debuggers\cdb.exe…
-
Want to persist your properties as markup?
Last week I got a request from a customer whom was developing a custom ASP.NET control targeted for other developers, and one of his requirements was to persist the control’s properties in the html markup, even for the default values which normally Visual Studio removes: since those are default values the assumption is that we don’t need to persist them in the markup (what usually happens is that if you change the value of a property through the property grid this is reflected in the html markup, but if you later set the value back to its default the designer removes the corresponding markup since it’s no longer needed), but the requirement here was to persist them anyway. To be honest I had never thought to this possibility (who knows, maybe I’m too used to do things in the Microsoft way ?) and despite my researches I’ve not been able to find this answer anywhere in our internal docs and samples, so we started working on a sample together (well, me from my office in Milan and the customer in his office in Crecchio, central Italy) and we also involved an Escalation Engineer (Radomir Zaric, thanks for your help!) to…
-
LogParser scripts for various occasions…
I’ve been working again with LogParser lately to extract some statistics for an IIS server which was facing a suspicious activity from the outside world: they were getting literally thousands of requests from a bunch if IP addresses to their page to request a “forgot password” for their online services. For this post is not important how we resolved the problem, but rather that of the occasion I had to create a few LogParser scripts to extract some statistics from the IIS logs, so I through those might be useful for other people too… Of course you’re free to change them to adapt to your needs. Before you proceed, a couple of words on the scripts: those are meant to be “generic” and run with a batch file which accepts some input arguments, but you can run them from a command prompt directly replacing the “%x” placeholders; also, I print them on multiple lines to be easier to read, but you must run then on a single line. This is to count how many requests you got to a specific page with a specific value in the query string (we were extracting data for the “change password” page with a…
-
The message received from the server could not be parsed
Again on the Ajax-compression subject (see here and here), here’s another error I got recently: Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled. The customer was using the GZipStream class within an HttpModule to compress the ASP.NET output; everything was working except in pages where he was using some UpdatePanel controls, where he was getting error messages like the above. As you can guess if you’ve read my previous posts, with http compression the response stream was being truncated. There are a couple of solutions available to this error: do not use the HttpModule and rely on IIS compression, or move the application to the .NET Framework 3.5. Remove the HttpModule from web.config Assure ScriptResource is not compressed: <scriptResourceHandler enableCompression=”false” enableCaching=”true” /> Open the IIS Manager Right click on “Web Sites” folder > Properties Click the “Services” tab Check “Compress application files” and “Compress static files” Apply and confirm all dialogs Stop IIS Open a command prompt and go to C:\Inetpub\AdminScripts Run the following commands to add .js, .aspx and .axd to the compression…