Those of us working with relatively high-level languages spend most of our time able to blissfully ignore the mucky little details that go into making a program actually run. C# allows us to not think about allocating and freeing memory, for example, or how our strings are terminated. It’s all too easy to extend this willful blindness to other details, like how numeric types actually work. Can this variable ever have a fractional part? Yes? Double! No? Int! Can it be really big? Long! Done, sorted.
Recently I was writing some functions to do unit conversions. Specifically, I was converting between points (1/72 of an inch) and EMUs (1/914400 of an inch). Part of the point of EMUs is that you can use them for high-precision values without needing floating point arithmetic, so I was storing them in a long. The application in question deals with fractional points, so those went into a double. Now, what’s the largest positive point that we can convert into an EMU without any overflow? If we do a little math we see that there are 12,700 EMUs per point, so the obvious answer should be long.MaxValue / 12700.0, which comes out to a bit over 7.2E14. Excellent. However, if I turn that around and convert that many points back into EMUs, I get -9.2E18. Oh dear. Continue reading A loss of precision, but not a loss of magnitude
Recently I was working writing a .NET web service as well as a client application to access this web service. I like to continually test throughout my development, and I noticed that this time, the .NET development server continued to switch ports every time I ran my application. This forced me to change my URL in my client app each time I ran the application as well. To resolve this issue I set the development server to have a static port instead of a dynamic port. Here’s how to do it: In Visual Studio 2008 if you’re using a web application project, right click the project and select properties. You will see the following web tab:
There you can set the specific port. In my case I set it to port 8080, but you can set it to anything you would like.
Recently I had a customer who was trying to use OfficeWriter with .NET 4.0 and kept receiving the error:
Warning MSB3253: The referenced assembly “assembly name” could not be resolved because it has a dependency on “System.Web, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” which is not in the currently targeted framework “.NETFramework,Version=v4.0,Profile=Client”. Please remove references to assemblies not in the targeted framework or consider retargeting your project.
The application was being compiled to the .NET 4.0 Client Profile. An application that targets the .NET Framework 4 Client Profile installs the minimum set of client assemblies on the user’s computer, without requiring the full version of the .NET Framework 4 to be present+.+ This is a problem because the System.Web assembly is not included—but OfficeWriter has a dependency to System.Web (which is not available in the Client Profile).
The solution: you will need to build your console application against the full .NET 4.0 Framework, because of the dependency on System.Web
To do this, just right click on your project in the solution explorer, go to properties and set the target framework under the application tab to .NET Framework 4.
Just rebuild your application and you should be good to go.
I want to upgrade a Web site from ASP.NET 2.0 to 4.0 without resetting IIS because it is running on a production server. The tool to do this is the ASP.NET IIS registration tool, aspnet_regiis.exe, which comes with ASP.NET 2.0 and 4.0. This tool doesn’t come with ASP.NET 3.0 and 3.5 because they’re both based on CLR 2.0. In fact, you don’t set a Web site or application to use ASP.NET 3.0 or 3.5, as IIS only knows about CLR version. See Scott’s Hanselman’s article for an excellent explanation. The .NET Framework version 4.0 comes with the new CLR 4.0 and so a new version of the tool is available.
Since I want to upgrade the Web site to ASP.NET 4.0, I’d run the 4.0 version of aspnet_regiis.exe, which is found under %systemroot%\Microsoft.NET\Framework\v4.0.303319. According to MSDN, to avoid interrupting IIS, I should use the -s switch to specify only the desired site or application as well as the -norestart switch to inhibit a restart. The value for the -s switch should be the path to the site; however, it may not be clear what this value should be.
To get a list of the paths and their registered ASP.NET version, I executed aspnet_regiis -lk and got the the following: Continue reading Upgrading IIS Web site or application to ASP.NET 4.0
||Although this configuration works on Windows Server 2008 R2, it is unsupported by Microsoft. Use at your own risk.
Use these steps to install ASP.NET 1.1 on either Windows Server 2008 x64 SP2, or Windows Server 2008 R2.
- Follow all of the steps in How to install ASP.NET 1.1 with IIS7 on Vista and Windows 2008
- Then implement this workaround for an acknowledged bug: Workaround: Running ASP.NET 1.1 on Vista SP2/WS08 SP2
- Ensure that the “IIS Metabase Compatibility” Role Feature is installed in IIS
- Download and install:
- Make sure ASP.NET 1.1 is enabled under ISAPI and CGI Restrictions
- In my experience, this has already been enabled after installation
- Add this IgnoreSection handler to the <configSections> element on the .NET 1.1 machine.config, located in %windir%\Microsoft.NET\Framework\v1.1.4322\CONFIG
I’m working on a project for a large consulting customer. The application we’re developing has a SOA that uses WCF services to return data. A requirement is that the data be communicated using XML for maximum interoperability between potential heterogenous (Microsoft and non-Microsoft) environments.
The problem I’ve run into is that some of the data sets can be quite large. We’re using the built-in functionality of the ASP.NET DatSet object to serialize the data and table schema information to XML. This is very fast and convenient to code, but the generated XML is very verbose and adds a lot of overhead. This resulted in errors in clients of the web service with the message “The maximum message size quota for incoming messages (n) has been exceeded“. I increased the MaxReceivedMessageSize property on the binding in the web.config file to 50000000 (yes, that’s 50Mb), but I still ran into the same error. I really didn’t want to keep increasing the max message size and be sending 50Mb, or even more, of XML across the wire. Continue reading Reducing the Length of XML Data Returned from a Web Service