Browsing to NET framework directory to reference higher version asssemblies: please advise.

Question

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))

Posted 11-May-18 10:16am

RedDk

Updated 11-May-18 10:35am

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Dave Kreskowiak · Answer 1 · 2018-05-11T10:37:00

Solution 1

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.

Posted 11-May-18 10:37am

Dave Kreskowiak

Comments

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.