Click here to Skip to main content
14,733,443 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I haven't asked a question for a long time but these two are so prescient that I'd be very surprised if the matter hadn't come up at some time in the experiences of many if not most CPians here at some point in their experiences using Visual Studio.

First, has anyone ever BROWSED (not made an .NET ref) to the Microsoft Framework (.NETFramework) directory to make a reference to a CLR assembly of higher order than the top-level version of the assembly accessible to them through their running version of Visual Studio?

And second, has anyone ever encountered the uncanny ability to successfully compile a CLR assembly using code that was presumeably designed to accesss functionality of a newer version of .NET Framework because the code doesn't reference any new real-estate of that newer Framework, ie: functionality through references new or otherwise?

These because I'm completely stopped in my tracks by being able to get a .dll that registers through a TSQL execution, allows me to run SQL Server nicely ... and then halts when the first call to the Assembly through Procedure EXECUTE gets told by Windows that "The given assembly name or codebase was invalid."

Or am I just too thinned skin and making Friday harder than it needs to be?

What I have tried:

(Wendelius' excellent "Writing into a file from databse" ... gutting the VS2013 project by removing it's innards, and reassembling them in Frankestein- fashion in a VS2010 project, and attemping to run the .dll produced by proxy through ssmse script execution (again wonderful .sql script provided by Wendelius))
Updated 11-May-18 11:35am

1 solution

You cannot use assemblies in your app that target a Framework version higher than the one your app is targeting.

While you may find cases were this will work, there are plenty of cases where it won't, and it seems you just found one.

This is specially so if your app is targeting .NET 2.0, 3.0, or 3.5, and your trying to use an assembly from any of the .NET 4.x versions.

Don't do this. It's not worth it.
RedDk 11-May-18 16:44pm
I just can't get over the fact that I'm able, in VS2010, to ... see the workspace in the UI completely unblemmished by jagged red lines under code that has no references to a "referenced" CLR assembly! It seems to me that I shouldn't have to get to the point where Windows is issuing it's proclamation from the third party app using that VS product.

And on that "Don't do this. It's not worth it" ... so you have done this and you're saying don't bother. Yeah, there's never any point to not doing something because it involves the outlay of cash.

An on that note, it's time to upgrade to Visual Studio 2018 64-bit. Yeah!
Dave Kreskowiak 11-May-18 17:15pm
I say "Don't do this" because the cases where a referenced assembly that targets a higher version framework in a lower version framework app are low. It's not worth the effort to "make it work".

You cannot run code that targets a .NET 4.x CLR under the .NET 2.0 CLR. You can, however, go the other way. Code that targets the .NET 2.0 and 3.x Frameworks will still work under the .NET 4.x CLR.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900