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.
Related
From memory, Microsoft took AppDomain away, and this mechanism has been shut down.
Now I suddenly find AppDomain has come back:
Assembly System.Runtime.Extensions, Version=4.2.1.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a\dotnet\packs\Microsoft.NETCore.App.Ref\3.0.0\ref\netcoreapp3.0\System.Runtime.Extensions.dll
the assembly contains the AppDomain class.
Here is my question: why?
Porting to .NET Core
Why was it discontinued? AppDomains require runtime support and are
generally quite expensive. While still implemented by CoreCLR, it’s
not available in .NET Native and we don’t plan on adding this
capability there.
What should I use instead? AppDomains were used for different
purposes. For code isolation, we recommend processes and/or
containers. For dynamic loading of assemblies, we recommend the new
AssemblyLoadContext class.
Furthermore
Of course, just because something isn’t
available in .NET Core today doesn’t mean we discontinued it. In most
cases, it simply means we haven’t had the time to investigate whether
porting would make sense or didn’t think it was relevant to the
application models .NET Core currently offers. Thus, this is an area
we’re highly interested in getting your feedback.
So what is actually supported?
AppDomain Class
On .NET Core, the AppDomain implementation is limited by design and
does not provide isolation, unloading, or security boundaries. For
.NET Core, there is exactly one AppDomain. Isolation and unloading are
provided through AssemblyLoadContext. Security boundaries should be
provided by process boundaries and appropriate remoting techniques.
It's there for certain tasks, however it's not supported in a lot of
ways.
Applies to
.NET Core
3.0 2.2 2.1 2.0
.NET Framework
4.8 4.7.2 4.7.1 4.7 4.6.2 4.6.1 4.6 4.5.2 4.5.1 4.5 4.0 3.5 3.0 2.0 1.1
.NET Standard
2.1 2.0
So what happens if you use something that is not supported?
It's either not there, or you get a big nasty evident throw new NotSupportedException or PlatformNotSupportedException depending on the when where and whys
Further reading
https://github.com/dotnet/standard/blob/master/docs/faq.md#is-appdomain-part-of-net-standard
https://github.com/dotnet/standard/blob/master/docs/faq.md#why-do-you-include-apis-that-dont-work-everywhere
We have recently taken on support of a web application that was written many years ago and targeted v1.1 of the .net framework. It runs on Windows Server 2003/IIS 6 environment.
After looking at the configuration of the site in IIS the target framework is set to 2.0.
Given that extended support for .net 1.1 will cease in October of this year (http://support.microsoft.com/lifecycle/?p1=1249) I am trying to ascertain whether the site will still use any of the .net 1.1 framework assemblies given that the application is built and compiled in Visual Studio 2003.
I am assuming this is the case because although ASP.net 2 is set as the target framework
in IIS (and therefore the aspet_isapi.dll invoked is the .net 2 one etc) the assembly is a .net 1.1 assembly and will therefore still use the 1.1 framework. However, is this assumption actually true?
The website only has another year or so to live before being replaced by a new solution entirely so I would prefer not to upgrade it if possible and run the risks such changes bring with them.
However, we obviously can't run something on an unsupported version of the framework if any element of if that framework is actually being used.
Any thoughts would be appreciated.
Update:
It would seem that .net 1.1 is a core component of WS2k3 so you can't just uninstall it. I could have attempted to remove the ASP.net component but I don't think that would fully uninstall everything and given that the dev environment is shared I can't risk causing any issues right now.
However I have previously set everything up on my local machine (Windows 7/IIS 7), so I changed the application pool to point at .net 2 (it was already running in classic pipeline mode), uninstalled .net frameworks 1 and 1.1 and cleaned up the files left behind afterwards.
The result was that the site ran absolutely fine, which would suggest in an IIS 7 environment at least that I don't need to worry about upgrading given we are running under .net 2 within IIS.
It's not an ideal test as it isn't a mimick of our live environment. I'm going to post a question on MSDN and asp.net to see if any Microsoft folks can add anything more definitive. I will post back here with any updates.
Just because official support will end doesn't mean Microsoft will pull the plug and force an uninstall of .NET 1.1 via Windows Update. It only means that:
if a gaping hole in the framework's security is ever found, they'll not fix it;
There won't be redistributables for the next versions of Windows, and the next version of IIS won't run it.
So the application will still run in a year. If you leave the server alone, the application might run until the machine breaks of old age.
So my suggestion is relax, and focus more on the new solution.
I got the answer to this questions after reading this link (provided as an answer to this question on the ASP.net forums)
http://msdn.microsoft.com/en-us/library/ms994381.aspx
Under "Application Load Mechanisms and Possible Issues" it states:
By default, an application built using the .NET Framework will run using the version of the Framework it was built against if that version is installed on the computer
It then goes on to detail (for .net 1.1 and 2.0 at least) when a particular version of the framework is used.
Essentially, because our server has both 1.1 and 2.0 installed the application will still be using version 1.1. If 1.1 was not installed then it would run by default under 2.0, which explains why the web application still worked after I uninstalled .net 1.0 and 1.1 from my local machine.
Given that the live server is W2K3 and I can't remove .net 1.1, I will be rebuilding my application to target .net 4.0.
what are some things i should be aware of before i begin this project? i've notice a few differences between this 1.1 site and our 2.0 sites: i noticed that every code behind file has a "Web Form Designer Generated Code" region which i'm guessing i won't need to transfer over to the 2.0 site.(?) There's also a "sitename".dll file in the bin folder which i was told is also a 1.1 thing and that dll file won't need to be transferred over to the 2.0 site.(?) at this -LINK-, the second answer mentions that my new 2.0 site should be created as a Web Application Project and not a Web Site project - does this apply to all 1.1 to 2.0 upgrades and should i consider doing this?
i would appreciate any advice at all on a 1.1 to 2.0 upgrade that you have. i should also mention that i am not allowed to upgrade to either 3.5 or 4.0 - it has to be 2.0. thanks.
2.0 brought a new project type for websites which, in the simplest terms, does not produce a dll for the website like 1.1 projects would. There was a patch released that supported the 'older' project type if you really hated the new website project (which I did).
To be honest I did not have that much trouble converting my sites over to 2.0 way back when it came out. Visual studio automatically converted my projects and I only had a few bugs to work out to be honest.
Try using the automatic upgrade (simply open the project in visual studio 2005 after you install 2.0) and see if you have any issues.
Be sure to install the latest service packs and be sure to test, test, test. .NET 2.0 added some fixes that amount to breaking changes in .NET 1.1. You may run into them especially in the area of XML processing in general, and XML Serialization in particular.
Note also that .NET 3.5 is nothing more than .NET 2.0 plus some additional assemblies that your code does not use. There is no good reason to not upgrade to .NET 3.5 SP1.
There are potential reasons to not upgrade to .NET 4.0, though not very many.
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.
I have an application written in ASP.NET 1.1. If I switch IIS to use 2.0 what issues am I likely to see? Initial tests have thrown no problems, but I was wondering if anyone had experience of running ASP.NET 1.1 applications under 2.0 and could maybe point out some areas to watch out for?
Thanks for any advice.
Just make sure that you are not running different web applications in the same application pool if they require different versions of the .NET framework.
Create separate app pools (at least one for each version of the framework).
Maybe also have a look at this blog post by Brad Abrams about breaking changes between .NET framework 1.1 and 2.0. Here's a short quote :
...we work very hard to ensure that
your V1.1 apps will this just work on
2.0, but none-the-less, this doc is likely worth a quick scan as you
migrate to 2.0
When we migrated our 1.1 applications to 2.0, I don't think we had any problems. There were a handful of cases where the compiler warned us that we should use a different (updated) assembly, but other than that everything was fine.
Most ASP.NET 1.1 applications will run just fine under ASP.NET 2.0. One thing to watch though is that you don't run an ASP.NET 1.1 and an ASP.NET 2.0 application in the same application pool.
The biggest problem we had was connected with the insertion of the xhtmlConformance element in the web.config file connected with javascript libraries, removing it worked fine for us
check this post from Scott Gu.
Usually asp.net 1.1 application migration to 2.0 does not raise any issues. You might need to change the location where you put the class files.
You will see some warnings, some deprecated method call etc.