|
|
That was quick!
I figured it was an easy one, so it'd either survive all day or get solved fast, but that was faster than I expected - well done. 
I liked it though.
You are up tomorrow.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
... together we'll do extraordinary things. (emphasis on the extraordinary)
|
|
|
|
|
Recently a demon made me create a Core project, and then attempt to use it in a WinForms app. And, yes, I altered the project files of both to enable C# 8.
The Core project does nothing but define a stupid little Class with one method that writes to the Console..
So, okay, I add a reference to the Core project dll to the WinForm app. I attempt to use it ... well, I m not surprised it didn't work, but was surprised to get a file-not-found error:Quote: System.IO.FileNotFoundException HResult=0x80070002 Message=Could not load file or assembly 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
Source=TestUsingCore
StackTrace: at TestUsingCore.Form1.Form1_Load(Object sender, EventArgs e) in ...
So, I set out to do some research, came across this article by Scott Hanselmann: [^].
I have great respect for Scott, and have learned a lot from his writing over the years; however, this article, titled "How to reference a .NET Core library in WinForms - Or, .NET Standard Explained," ignores the question in the title and ends up recommending ".NET Standard" as if that explains anything.
Was Scott avoiding the simple answer that you cannot use a Core project/class in a WinForm app for some reason ? Well, okay, Scott wrote that in June, 2017: that's decades ago in .NET's evolutionary time-scale.
To turn my headache into a full-on migraine, I then re-read this article: "How to port desktop applications to .NET Core 3.0" [^].
Whaddya think ?
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
|
I can understand, once upon a time I found it confusing too, I remember....
But now, with the benefit of experience and understanding, I would say it's pretty neat and good.
Core is a Runtime... when an application is compiled for .NET Core it runs with the .NET core runtime....
Using a .NET Core library on another runtime (such as the .NET Framework) is a little bit of a gamble, I imagine.
.NET Standard is a, for lack of a better word, a "runtime contract" a .NET Standard library (only library, no executable) can be run by any runtime supporting this version (or above) of .NET Standard.
It replaces and simplify what was previously known as PCL (Portable Class Library, not really portable, more like multi targeting)
Hence if you want to make a library for multiple platform, make it a .NET Standard library.
.NET Core, by contrast, is a runtime, like Unity, (iOS, Android) Xamarin, .NET Framework.
And.. good luck with your experimentation! 
Hope it brings you some wins in the end!
modified 27-Oct-19 22:44pm.
|
|
|
|
|
 thanks, Lloyd, you make more sense than Scott did !
Given I am trying to use a compiled Core project (dll) in a WinForms project, do you think it possible that some modification could be made to the Core project so that it somehow included the necessary run-time ?
cheers, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Thanks Bill!
I remembered being very confused by all the Microsoft document about all those runtimes thingy... Dunno why they do such a bad job of explaining it....
But ultimately once you play with it in Visual Studio it's not that hard...
To your question I am not sure how one would do it (using a .NET Core library in the .NET Framework app or vice versa) it seems hackish...
But why don't you do like Scott suggest? which is a very successful code sharing pattern in the latest .NET age!
I.e. make ALL your utility libraries .NET Standard libraries.
.NET Framework 4.7.2 and .NET Core 3 both support / implement .NET Standard 2.0. And .NET Standard 2.0 cover pretty much every multiplatform needs!
The only pain point I can think of is how about some WinForm code that would work on BOTH .NET Framework and .NET Core.
Dunno about that one, haven't done much home research lately...
Might have a go this weekend... "might" no promises.. 
|
|
|
|
|
Your WinForms project needs to be .NET Core to reference a .NET Core library. Referencing a .NET Core library from a .NET Framework project is not a supported scenario. It can go the other way though - a .NET Core project supports adding references to .NET Framework libraries, but keep in mind there may be a few APIs that aren't available in .NET Core. It's fairly rare that you'll run into this though.
Just remember - .NET Core new and backwards compat, .NET Framework old. You can't add a reference to a new .NET Core library from an old .NET Framework project. That would be like trying to add a reference to a .NET 4.7 library from a .NET 2.0 project...wouldn't work.
|
|
|
|
|
As for WinForm control library...
Damn... you could do that with PCL, compile for multiple targets!
But you can't.
Anyway as the other poster suggested, it seems like you can make a .NET Framework control library and use it in your .NET Core app!
|
|
|
|
|
Was it this demon per chance?!  
On a side note, Googling for "Thailand computer demon" brought me to this...
So pretty! I need some holidays now, haha 
|
|
|
|
|
Your WinForms project needs to be .NET Core to reference a .NET Core library. Referencing a .NET Core library from a .NET Framework project is not a supported scenario. It can go the other way though - a .NET Core project supports adding references to .NET Framework libraries, but keep in mind there may be a few APIs that aren't available in .NET Core. It's fairly rare that you'll run into this though.
Just remember - .NET Core new and backwards compat, .NET Framework old. You can't add a reference to a new .NET Core project from an old .NET Framework project.
|
|
|
|
|
It was a lot hairier than that 
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
OK, ok … where is the computer ? On the boat maybe …
|
|
|
|
|
I assume the WinForms project is .NET Framework (it could be .NET Core since last month).
.NET Framework and .NET Core are not fully compatible and while I believe it's possible to reference .NET Core projects in .NET Framework and vice versa it's not recommended.
Instead, you should use .NET Standard, the common denominator between the two.
You can simply add a new project in Visual Studio and pick the "Class Library (.NET Standard)" template.
This project will be usable in .NET Framework and .NET Core projects (but it can't run on its own since it has no runtime).
Be sure to write your .NET Standard project in the correct version: .NET Standard | Microsoft Docs[^]
|
|
|
|
|
> Instead, you should use .NET Standard, the common denominator between the two.
Since when do Linux and Mac natively support .NET Standard, and since when do all Servers inherently have it installed? It's almost as if people have specific use-case scenarios for requiring .NET Core...
-= Reelix =-
|
|
|
|
|
|
|
.NET Standard isn't a runtime, so it's not installed on any machine.
.NET Core applications can be deployed as stand-alone applications that come bundled with the runtime though.
And I guess the .NET Core runtime can be installed on Mac or Linux directly as well, as you can on Windows.
I've never targeted Mac or Linux, but that's what I understand.
And in any case, you should use .NET Standard if you want to use a library in .NET Framework (and run it on Windows) or in .NET Core (and want to use it cross-platform) or Mono or Xamarin.
|
|
|
|
|
You can use a netstandard library, remembering:
Netstandard is just an API specification. The underlying framework to use could be full framework, core or mono. Which version of each depends on the netstandard version you're targeting, for instance, netstandard2.0 ~ net framework 4.6.2 / netcore 2.2 (iirc)
So a netstandard library won't provide the framework (just like other libraries won't) and relies on a shimming layer to get between the runtime you're providing (typically core or framework) and it's logic, and back again.
Just install the Nuget packed System.Runtime.
On the other hand, I've had some assembly binding woes with netstandard stuff, but that's b cause msbuild is being dumb and trying to upgrade dependencies (even ones that I've installed from nuget) to point at shined versions from machine-local netstandard, a problem which may not become evident until you have a significantly complex dependency chain, and simplified greatly if you can just update everything to latest (I can't, just yet)
YMMV
|
|
|
|
|
|
BillWoodruff wrote: Whaddya think ?
Why would you want to reference a Core project in a WinForm app?
Why would you want to port a desktop application to .NET Core?
If I wrote a blog about those two questions, they would be very short: "I wouldn't."
And while I have written .NET and .NET Core that work together, they work together over a communication protocol, like HTTPS! 
|
|
|
|
|
Marc Clifton wrote: And while I have written .NET and .NET Core that work together, they work together over a communication protocol, like HTTPS!
Same can be used for C# and C++ without having to marshal the hell out of parameters
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: Same can be used for C# and C++ without having to marshal the hell out of parameters
Exactly!
|
|
|
|
|
The latest version of Core supports WinForms. I don't understand why there's an issue. Of course, I don't understand why anyone would write Core apps to begin with, so there is that. (No, I don't concern myself with "cross platform" crap.)
IMHO, Core and Docker are solutions looking for a problem. Of course, I'm old and resist change in any disguise.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
