I've written some code using the REST starter kit and it works fine on my development machine. However, when I upload it to our server the page gives me the following error message...
CS1684: Warning as Error: Reference to type 'System.Runtime.Serialization.Json.DataContractJsonSerializer' claims it is defined in 'c:\WINNT\assembly\GAC_MSIL\System.ServiceModel.Web\3.5.0.0__31bf3856ad364e35\System.ServiceModel.Web.dll', but it could not be found
I've removed code line by line and it appears that the following line of code is triggering the error...
HttpContent newOrganizationContent = HttpContentExtensions.CreateXmlSerializable(newOrganizationXml);
Really haven't got a clue how to fix it. I assumed it might be because it needs a newer version of the framework to run, but looking in IIS it says it's running version 2.0.50727 which I think is the lates version because it says that even when we're using framework 3.5
Very confused, any ideas?
Jon
At first I thought this was possibly because the server you're deploying to didn't have .NET Framework 3.5SP1 installed and only .NET 3.5RTM.
However, upon checking a .NET 3.5 RTM System.ServiceModel.Web.dll assembly I see that the System.Runtime.Serialization.Json.DataContractJsonSerializer is actually defined.
The compiler warning CS1684 suggests that there is a System.ServiceModel.Web.dll assembly in the server's GAC, but one that doesn't have the System.Runtime.Serialization.Json. DataContractJsonSerializer defined.
So things I would check:
Check that the deployment server is running at least .NET 3.5 RTM and that a beta or release candidate isn't in use or hasn't been left over.
In Visual Studio 2008 make sure you select a "Target Framework" of .NET 3.5 in the project properties.
One final check you could do to see if the problem lies with the server's framework install is to knock up a simple application to consume the DataContractJsonSerializer directly. There's an example on the MSDN documentation page for the class:
DataContractJsonSerializer Class (MSDN)
As a last resort, if the server is under your control then I'd uninstall .NET Framework 3.5 and then re-install from:
Microsoft .NET Framework 3.5 Service Pack 1 (Full Install)
Update:
As per your comments:
If you're running a beta of 3.5 then chances are that DataContractJsonSerializer isn't in the System.ServiceModel.Web.dll assembly.
I seem to remember back around the CTP, betas and release candidates there were late breaking changes in this area. I vaguely remember the DataContractJsonSerializer was one of these late additions/changes due to the increased popularity of JSON and community pressure. My memory is a bit vague but it rings a bell.
To replace the DLL you need to unregister the current version from the GAC then register the RTM one using the GACUTIL.exe tool. I wouldn't advise mixing RTM and beta bits, you're leaving yourself open to unpredictable behavour.
Related
I don't have access to an IIS server but I am told that the site is configured to run with version 1.1 of the .NET Framework. When I use Telerik JustDecompile I see the following.
The "NET 1" seems to suggest that the 2 dlls are compiled against version 1.1 of the FW. Does the "ANY" next to the website dll "GLSS" indicate that the site can run against any version ofthe .NET FW that is installed on the web server?
In preparation for an upgrade to 2.0, I have asked the web admins to change the site configuration to version 2.0 of the FW and I was surprised that the site, which I considered to be running 1.1 code, still worked. Should I be surprised?
Is this just a simple example of backward compatability and that the site could be configured to use any version of the framework provided that it was equal to or higher than the version that the code was compiled to use?
when I look at the property pages for the projects in the solution, I was surprised that, for the website project only, I was unable to locate where one sets the version of the FW which you want to compile against. I was able to locate it for the referenced projects.
Can you help me better understand the relationship between the version of teh FW that a site is configured and the versions that the assemblies are compiled against?
You should not be surprised, .NET was always backward compatible in a sense that assemblies compiled against a version of the runtime are supposed to run against a newer version of the runtime.
There are of course subtle issues where things are not backward compatible, starting from subtle semantic differences and ending with changes at the object contract level (where the expected method/class just does not exists anymore) but in general these problems depend on the complexity of your application. It is safe to assume that simple applications should just work with no issues.
The number of the runtime the assembly has been complied against is a part of the assembly's metadata, it can be read with reflection. Thus, at runtime, you have at least two possible versions of the runtime - the one the assembly has been compiled against and the current version of the runtime which executes your code.
I'm working on a .Net 3.5 WebForms application and this morning I noticed this message in my debug window:
This application is using the
HMAC-SHA-384 or HMAC-SHA-512 keyed
hash algorithm. The implementation of
these algorithms were updated in
service pack 1 of .NET Framework 2.0
and by default do not produce results
consistent with the unserviced
versions of the classes. For more
information about the changes to the
algorithms and how to disable this
warning message please see the release
notes for service pack
1.'WebDev.WebServer20.EXE' (Managed (v2.0.50727)): Loaded 'Anonymously
Hosted DynamicMethods Assembly'Hosted DynamicMethods Assembly'
This is the only reference I can kind to this kind of message is in reference to .Net 2.0 (without a service pack). Since I'm working on .Net 3.5 I'm assuming that that particular bug has now been fixed.
I'm unsure of how long this message has been appearing in my debug window and have no idea if it's a real problem, or if I can just ignore it.
Has anyone else seen this?
Judging from the text and the blog post, you are save on all frameworks starting with 2.0 SP 1. Hashes made by earlier frameworks will yield the same results as .net 2.0 SP1 (or later), or any other implementation out there.
I'm working on Visual Studio Profesionnal 2010.
In my solution I've got 2 projects
The first is a web site with targeted .net runtime 2.0
the second is a dll with targeted .net runtime 2.0
I add the output of the second as assembly of the first.
I build and rebuild and clean my solution
result : Build succeeded
But when I launch the projet in my web-browser ( in debug or release ).
I've got the Server Error :
This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded
Is there someone who had already the problem?
I think it can be a bug from Visual Studio 2010 but the hotline is very expensive
300€ the phone call.
More Information :
I opended my dll with reflector and saw that mscorlib is referenced 2 times
the first time Version = 2.0
and the second time version = 4.0
Open the .csproj file with text editor (e.g. Notepad) and see the references in there.
If there are references to frameworks higher than 2.0 remove them or change to 2.0 if possible, save and reload the project.
I am pretty sure that this means that you built with asp.net framework 3.5x, but your server only has 3.0x. Update the runtime on the server.
Your server can only support 3.0, Updating the server will resolve the issue..
Opening a .Net 2 project in VS2010 it converts the project without any issues BUT when I attempt to build it fails.
The reason is that in VS2005 a reference was added to System.Web.Extensions which is a .Net 3.5 assembly. Now VS2005 never complained at this and quite happily worked but VS2010 is far more strict and won't allow it.
I've tried changing the targeted framework to .Net 3.5 but I get another situation there where the web page is never displayed, it simply hangs not even getting to Applicatin_OnStart.
Any help either on adding the reference with .Net 2 as target framework (prefered option for time) or getting the .Net 3.5 version to work would be greatly appreciated.
[Edit]
Ok so maybe the reference was a read herring. One of my colleagues opened the project and did the conversion and once he changed the targetted framework to .Net 3.5 it all worked. The difference between our machines is that he's on 32 bit XP and I'm on 64 bit Windows 7. When I change the targetted version and try to run the program the build seems to stop at CppCodeProvider and hang.
[Edit]
Check your web.config file for the references to System.Web.Extensions. It could be there are duplicate entries or entries pointing to older versions.
Check if the project is just targeting the client profile. The following link could provide you additional information: System.Web.Extensions Assembly cannot be resolved
I had an ASP.NET 2.0 web project. Worked fine. I decided to upgrade the site to 3.5. The upgrade worked fine. I have added a IHttpHandler that required to include the following line in the web.config:
<add verb="GET,POST" path="MyOperation.asmx" type="MyClass"/>
This line in the web.config generates the following error: "Parser Error Message: Could not load type 'MyClass'."
This sounds like a typical spelling error in the class name. But it looks not, I checked it 1000 times. However, what is really strange that on the bottom of the "yellow-screen-of-death" page it says:
Version Information: Microsoft .NET Framework Version:2.0.50727.3082; ASP.NET Version:2.0.50727.3082
This is really strange. The project is set to 3.5. The only piece of code that use 3.5 features are the IHttpHandler implementation. All the rest of the web project are 2.0 compatible and works without problem if I exclude the line from the web.config.
Why is this?
[I did not try with IIS. I use ASP.NET development server.]
[EDIT] I have to apologize, it was stupid spelling issue as I expected in the first round. My IHttpHandler implementation was in a nested class and the proper class name is "OuterClass+NestedClass" vs OuterClass.NestedClass that I used in my config file. However, I thank to all who contributed because I learned new things on CLR versioning!
I think you need to use the fully qualified type name.
Like:
<add verb="GET,POST" path="MyOperation.asmx" type="Your.Namespace.MyClass, assembly.name"/>
and the error containing the version information of 2 is normall since the CLR hasn't changed for 3 and 3.5. the only changes were additional sepperate assemblies and syntactic suggar (like automated properties are a feature of the compiler not the runtime) ".net 4" will come with a new CLR.
The version is not an issue ( I think). .net 2 to 3.5 sp1 use the same run time. The newer ones are just new libraries and compilers. So from the asp.net point of view not much has changed.
ASP.NET 3.5 is really 2.0 with extra extensions. So, as long as the server has 3.5 installed, then the message that shows that you're pointing to the 2.0 framework confirms that you have it setup correctly.
The issue is likely what olle suggested, that you need the full class name, assembly name.
Also confirm that you have the dll in your /bin folder and that it's marked as an application if you're not working from the root of your site.
Go to the project properties. Choose the Application tab. Change the Target Framework to .Net Framework 3.5 if you haven't done that already.