System.Web.HttpParseException (0×80004005): Cannot create an object of type ‘System.Type’ from its string representation ‘System.Int64′ for the ‘DataType’ property. —> System.Web.HttpParseException (0×80004005): Cannot create an object of type ‘System.Type’ from its string representation ‘System.Int64′ for the ‘DataType’ property. —> System.Web.HttpException (0×80004005): Cannot create an object of type ‘System.Type’ from its string representation ‘System.Int64′ for the ‘DataType’ property. at System.Web.UI.PropertyConverter.ObjectFromString(Type objType, MemberInfo propertyInfo, String value) at System.Web.UI.ControlBuilder.AddProperty(String filter, String name, String value, Boolean mainDirectiveMode) at System.Web.UI.ControlBuilder.PreprocessAttributes(ParsedAttributeCollection attribs) at System.Web.UI.ControlBuilder.Init(TemplateParser parser, ControlBuilder parentBuilder, Type type, String tagName, String id, IDictionary attribs) at System.Web.UI.ControlBuilder.CreateBuilderFromType(TemplateParser parser, ControlBuilder parentBuilder, Type type, String tagName, String id, IDictionary attribs, Int32 line, String sourceFileName) at System.Web.UI.ControlBuilder.CreateChildBuilder(String filter, String tagName, IDictionary attribs, TemplateParser parser, ControlBuilder parentBuilder, String id, Int32 line, VirtualPath virtualPath, Type& childType, Boolean defaultProperty) at System.Web.UI.TemplateParser.ProcessBeginTag(Match match, String inputText) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ProcessException(Exception ex) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath) at System.Web.UI.TemplateParser.Parse() at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType() at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean throwIfNotFound) at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp) at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

This page was working perfectly on 2 development environments and 1 staging environment, and they all had the same version of the controls installed (BIN installed).  But when deployed to the production server, the page errors out with this stupid error.

Telerik’s explanation is that the telerik.web.ui.dll and the telerik.web.design.dll have different versions, but this was not the case as I verified versions were correct, rolled back to the previous DLLs prior to the deployment, etc.  I cleared the .NET temporary file cache, restarted IIS, restarted the web service, re-referenced the controls in the web.config, even tried updating the GAC.  Nothing worked.

I followed Telerik’s instructions (different than above) as well, to no avail.

Since I was working against a deadline for this deploy, my only solution was to remove the RadNumericTextBox and replace it with a RadTextBox and deal with the validation of the input on the server-side.

Great solution?  No.  A solution at all?  Definitely not.  But I wasn’t about to wait to hear back from Telerik with their generic responses and then start shooting in the dark all over again.

So the work-around presented in the previous post will get you by, but it’s not a solution.  I set up a script to run the diskpart script every hour, and still, I found that it was almost happening randomly. I noticed that it only happened on my Disk 2 which was on the built-in SATA controller using the JMircron chipset.  Interesting.  After I installed the new RAID array (here) I noticed that now my system drive was now listed as Drive 2, and that in fact it was being listed as read-only and my script no longer worked.  What a pain in the butt.  It was especially annoying since SQL Server and IIS would start failing since they couldn’t write to the system drive.  What a mess.

At this point you have to step back and consider the situation.  I just upgraded some hardware and the situation changed, but after numerous software changes the issue remained.  So what’s hardware related but lives in software such that it can tell the OS that a disk is read only?  The answer is, a driver.

Then began my quest in searching for a driver issues with the JMicron chipset.  Low and behold, it’s a known issue.  Once I installed an updated the driver, the issue that would bring my server to a halt VANISHED.

Link to JMb36X Windows Driver.

Make sure you research your set-up first before installing a random driver.  You’ll only make a bad situation worse.

Request.ServerVariables (server_variable)

Server Variables

Web Server -> WorkGroup -> Firewall -> Domain -> File Server -> Network Share -> SAN

As you can see, there are several issues are hand.  Not only do the accounts have to exist to allow for this communication (and an Administrator account is the only way to go), all sorts of permissions have to be valid for this to function (ie. Local Permissions within each OS on each Server, NTFS (file permissions) on each local server, Access permissions through the Firewall, Access permissions of Domain Resources, Local process level permissions, etc).  It was a nightmare, but I believe I figured it out.

There are a few things that needed to be done in this situation.  First, the permissions on the SAN needed to allow Administrators full control.  Additionally, the local user on the file server needed to have administrative privileges, to both the system and the SAN, thus allowing the network share.   Next, the firewall rules needed to allow file traffic (I can’t remember the SMB ports right now – and Windows needs netBios and something else to let file transfers go through, as well as authentication).  Finally, the Web Server local user needs admin rights.

To get this to work, I needed everything involved to run with elevated privileges, from IIS, to each thread in the application.  Since there was going to be a large amount of file movement, as well as resource and memory manipulation, it’s required.

Therefore, the admin credentials were inputted into IIS to map the network share from the Web Server to the File Server.  Next, I had to impersonate the admin user in each thread within the application, a pain, but the guide can be found via Google (if I have time, I’ll track them down again). Next, the machine.config needed to be modified to allow the ASP.NET process to run with the elevated permissions.  The web.config needs to be altered to allow impersonation with the credentials as well.

Now here’s the kicker, and something that’s not quite known but buried within Microsoft’s documentation.  For this to work (Work Group computer to authenticate to another computer) is to mirror the accounts (same username and password) on both servers (these are local accounts, not domain accounts – since the share was local on the server, the domain can be bypassed. If it were a domain resource, we would have to authenticate via NTLM to an Active Directory server, which would have been a bit more complicated).  This allows the hash sent from one system to another to be identical, and thus, you will authenticate (if you know the username and password on one workgroup computer, and it’s the same on another, chances are you’re who you say you are).

This took me a week to figure out, which was not enjoyable.  I hope this saves you some time.

Most people on installing .NET 3.5 on the server “expect” an entry for  v3.5 under the ASP.NET version Tab in IIS manager. And not finding that entry start panicking. If you have been one of those read on. The more tech savvy folks try to run aspnet_regiis -i from the v3.5 framework folder… but even that is missing

That brings us to the question

What exactly is ASP.NET 3.5 ?

Take a look at the v3.5 framework folder you will not find most of the files needed for ASP.NET to run like aspnet_isapi.dll / aspnet_filter.dll / aspnet_regiis.exe / aspnet_regsql.exe…

The reason being .NET 3.5 is not a stand alone framework like v2.0 or v1.1 . It is just an extension of the 2.0 framework. The extension provides developers with new language features like Anonymous Types, Extension Methods, Lambda Expressions and of course LINQ …. and AJAX is now integrated … also you have a few new ASP.NET controls <asp:ListView>, <asp:LinqDataSource>, <asp:DataPager>

Will I get ASP.NET version 3.5 under the ASP.NET tab in IIS 6.0 ?

Nope. Because as far as IIS is concerned nothing has changed. The aspnet_isapi.dll from the version 2.0 folder will still handle the requests and there is no new ISAPI dll specific to version 3.5. So you don’t have to change any Script Mappings in IIS …just leave the web application pointing to v2.0 under the ASP.NET Tab. And this brings us to the next question

What exactly is the extension ?

For that if you have Visual Studio 2008 go ahead and create a Website targeting the .NET 3.5 framework. Then go to the Property Pages of the Website and select References. You will find an entry like this

And those four assembly references provide the new features of v3.5.  Here is a 10,000 ft view of the functionality implemented in these assemblies

System.Core – Provides namespaces like System.Linq, System.IO

System.Data.DataSetExtensions – LINQ to DataSet

System.Web.Extensions – AJAX

System.Xml.Linq – New XML API.. supports LINQ to XML

Do I have to configure anything manually ?

No. When you install the .NET 3.5 redistributable on the server it installs these assemblies in the GAC. And any website that refers to these assemblies can fetch them from the GAC so you do not have to configure anything manually. All you need to do is publish the content to a web application that is marked with ASP.NET v2.0

And now you should be thinking

The new language features should require a new compiler. How exactly is the new compiler used ?

The answer is your web.config file. When you create an ASP.NET 3.5 website in Visual Studio 2008 an entry is made in the web.config something like

<system.codedom>
  <compilers>
    <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4"
              type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <providerOption name="CompilerVersion" value="v3.5"/>
      <providerOption name="WarnAsError" value="false"/>
    </compiler>

The new features do require a new compiler to be used and the web.config tells .NET that the v3.5 compiler has to be used.

What about IIS 7.0 ?

IIS 7.0 is no different.

I followed the very easy instructions and it ran great.  Here is a shorter version of the directions and the links to get everything you need:

1. Download and install IIS 6.0 Resource kit: here
2. Open the IIS Manager (Start > Run > inetmgr), open the properties of the Virtual Server website (usually the 2nd one) (right click > Properties)
3. Change the SSL port to 1024 (default VS port) and change the TCP port to 1020 (or any other port number) > Apply
4. Open a command promt (Start > Run > cmd) and go to the SelfSSL director (/program files/iis resources/selfssl) and run the following command > selfssl /N:CN=<FQDN>/K:1024 /V:730 /S:2 /P:1024
   1. Where <FQDN> is the website domain name (ie. steve-oh.com, yahoo.com, etc) and /S:2 means the second site on the server.
5. Now browse to the Virtual Server website and install the certificate and you’re done!

Now you have a Secure Socket Layer (SSL) connection from any remote computer to your server at 1028 bit encryption, so you can rest easy when logging in over the internet.