1

It's an odd question to ask, but I'll try.

I started my project using the target framework as 4.5.2, and the requirement was to sign a XML file using the SHA1 algorithm. I used the example in this MSDN page, and it worked fine:

SignedXml.CheckSignature Method (X509Certificate2, Boolean) -> Examples section
https://msdn.microsoft.com/en-us/library/ms148731(v=vs.110).aspx#Anchor_3

After that, the requirement changed to SHA256 algorithm. I used the code in those pages to adapt that original code, and it worked fine, I was using 4.6 as the target framework by that time:

Using SHA256 with the SignedXml Class
https://blogs.msdn.microsoft.com/winsdk/2015/11/14/using-sha256-with-the-signedxml-class/

.net Framework 4.6.2 adds support to sign XML Documents using RSA-SHA256
https://www.stum.de/2016/05/19/net-framework-4-6-2-adds-support-to-sign-xml-documents-using-rsa-sha256/

Then I discovered that the version 4.6.2 of the framework added full support for SHA256, and that the CryptoConfig.AddAlgorithm() call was not necessary any more. I changed the project to version 4.6.2, made the changes needed, commented the CryptoConfig.AddAlgorithm() call and it worked just fine.

But now we have another requirement change: We want our software to work under Windows XP (yes, we do have users still using it), and the last framework version to work with XP (SP3) is v4.0. So, I needed to test if signing a XML file with SHA256 would work in framework 4.0.

I changed the target framework to v4.0 then and started the changes. The RSAPKCS1SHA256SignatureDescription class that I used in the CryptoConfig.AddAlgorithm() call is only available since framework 4.5, so I would have to write my own version of it, as I saw in some webpages.

But, now the strange thing. I kept the CryptoConfig.AddAlgorithm() call commented to see what would happen, so I could write the custom class, but, it just worked!

I thought that CryptoConfig.AddAlgorithm() had registered the algorithm somewhere in the project, or my machine. I researched about that but found nothing. So I tried in another machine, and it worked too, but that machine probably had executed the previous code before, so it could had the algorithm registered also. I tried another machine, that one I was not sure, but worked there too.

So, I went to a machine that have never even seen the project, and that time I compiled it and deployed the executable (I was executing the VS project on the other machines). I removed all the .NET frameworks after 4.0 on that machine and tried to run the application. And... it still works! It signs the XML using SHA256, and works fine. All those machines are running Windows 10.

Someone have any idea what is going on?

Pedro Gaspar
  • 777
  • 8
  • 35
  • Often crypto algorithms are backported to older versions to keep compatibility. It might be a very easy answer like that. It could be that if you'd install Windows XP and the very first distributable of 4.0 that it will fail. Note that Microsoft has the nasty habbit of not keeping/showing real version information (files for 4.0.0 and 4.0.999 may have the same file name, just distinguished by the last change date). – Maarten Bodewes Jul 29 '17 at 17:40
  • But what is really strange is that when I started adapting the code to SHA256, it didn't work without the CryptoConfig.AddAlgorithm () call. And Iwas using framework 4.6. And now, with framework 4.0 it works. I will do just that, create a virtual machine with a clean Windows XP SP3 install and see what happens. – Pedro Gaspar Jul 29 '17 at 20:00

2 Answers2

1

The version you target and the version you're running in are not the same. Any target 4.0-4.7 runs on the 4.7 runtime. Since adding the support was non-breaking it was not done with a target version backout.

Since WinXP won't have 4.6.2 you'll need to add the handler yourself. Targeting whatever framework XP has will limit you to the API that was available, though as you've seen the runtime might behave differently, so you really ought to test on your destination OS.

bartonjs
  • 30,352
  • 2
  • 71
  • 111
  • You mean that, even if I'm targeting version 4.0, and I do have version 4.0 on the machine, but the machine also has version 4.7 on it, it could be running version 4.7 on my project instead of version 4.0? But then, why the call to the X509Certicate2.GetRSAPrivateKey() method stopped working just after I've changed the framework version? And why the compiled version of my application worked on a machine where I have uninstalled all the famework versions above 4.0? It still doesn't make sense to me! – Pedro Gaspar Jul 30 '17 at 15:49
  • Is there a way to check which version of the framework is being used by my appplication during runtime? – Pedro Gaspar Jul 30 '17 at 15:56
  • I'll try that: https://stackoverflow.com/questions/8517159/how-do-i-detect-at-runtime-that-net-version-4-5-is-currently-running-your-code – Pedro Gaspar Jul 31 '17 at 02:51
0

After Marteen Bodewes comment and bartonjs answer I've done some research and learned some things about the .NET Framework. In the past I really bought the Microsoft marketing about the side-by-side feature of .NET, but I always thought that every version of the framework would live together on the same machine. Today I've learned that's not exactly like that.

In first place, the CLR and the framework are different stuff that don't necessarily walk together. The Common Language Runtime (CLR) is the critical piece of the framework to tell if there will be side-by-side coexistence or not. By today there are only 4 versions of the CLR: 1.0, 1.1, 2.0 and 4:

Common Language Runtime (CLR) - Versions of the Common Language Runtime
https://learn.microsoft.com/en-us/dotnet/standard/clr#versions-of-the-common-language-runtime

All the framework versions that share the same CLR version, will be an in-place replacement of the previous version. So, if you have just Framework 2.0 on a machine, you have CLR 2.0 and Framework 2.0. If you install Framework 3.5 on that machine, you still have CLR 2.0 but the Framework 2.0 is replaced by the 3.5 version. After that, if you install Framework 4.0, you have CLR 2.0 and CLR 4 and Framework 3.5 and Framework 4.0. If you install Framework 4.5 on the same machine, you still have the CLR 4 but now the framework 4.0 is replaced by version 4.5.

That's why, at least on my machine, I have only v2.0 and v4.0 folders under 'C:\Windows\assembly' path. I've noticed that, during runtime, the .NET DLLs are loaded from that path. Still, I'm not sure what is the purpose of the 'C:\Windows\Microsoft.NET\Framework' stuff then.

But that didn't answer the question I asked to bartonjs: If the new version of the framework vanishes the previous versions that share the same CLR from that machine, how Visual Studio knows which classes, methods, properties, etc. are valid for that specific target framework chosen for the project?

So I found this excellent article by Scott Hanselman:

.NET Versioning and Multi-Targeting - .NET 4.5 is an in-place upgrade to .NET 4.0
https://www.hanselman.com/blog/NETVersioningAndMultiTargetingNET45IsAnInplaceUpgradeToNET40.aspx

And the answer is: Under the directory 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework' is an archive of all the versions that passed through the machine, and Visual Studio uses those! (why don't have all those things in just one place and have a really side-by-side coexistence then?)

After all these answers I understood better what was going on (by the way, I discovered that that last machine did have the framework 4.7 installed, because I uninstalled then all, but I was going to install Visual Studio Community 2017 on it, and cancelled to do my tests, but, the Visual Studio Installer had already been installed, and that one probably put the last framework on the machine), and was no surprise when it really failed when I executed the application under Windows XP SP3. But now I know exactly what to do.

Pedro Gaspar
  • 777
  • 8
  • 35