This issue is exactly as described in the title.
I have a portable F# class library. I have created an ASP.NET Core Web Application (both .NET Framework and .NET Core), from which I have tried to add a reference to my F# class library.
Trying to add the reference gives a message:
The following projects are not supported as references:
Project type is unsupported by current project and can not (sic) be referenced.
This is extremely disappointing, as the .NET Core is now in General Availability.
Are there any workarounds while this bug gets addressed?
I have a project, which I started with Beta8 bits of .net core and since then I have an F# library, which I use from an asp.net core C# app. (btw here is an RC2 based minimal sample for referencing the F# lib from a net core based console app)
Here is how I did it:
Currently (according to my knowledge) there is no template in VS to create a coreCLR based F# library (the PLC templates under F# are all Full framework based, but that you still cannot reference from asp.net core even if it runs on full framework), so you have to do this with the command line. This is done by:
dotnet new --lang F#
This creates you a hello world coreCLR F# app. You can turn the app into a class library by modifying project.json file.
If you have a VS solution and you click to “Add” -> “Existing project” you can select the project.json file. This way you add it to your solution (and btw. an xproj file will be also created).
So at this point you will have the coreCLR based F# project in your solution. I believe by right clicking the asp.net core project and go to “Add” -> “Reference” -> Projects->Solutions and selecting the F# library you can already reference it. If this does not work, you can do it manually: just list the F# project under the “dependencies” in the project.json of the asp.net core application.
If your asp.net core app runs on full framework still need to do these steps. It actually doesn't really matter.
Now the bad part:
In the RTM (released on Monday) the “dotnet new” command creates an uncompliable F# app, because of some dependency issues. This is tracked here (the title says "on macOS", but it's the same on Windows) and as soon as it’s solved this should be fine (or if you did not yet install RTM and you have RC2 you are also good).
Intellisense and debugging across F# and C# does not work (I posted it here)
Although .NET Core has officially been released, the vast majority of the nuget packages in the ASP.NET Core Web Application are in prerelease. Moreover, although the entity framework identity model has been cleaned up, my attempt to change the key columns for users and roles from strings to ints generated an obscure error when I tried to implement Entity Framework migrations. I know I can do it for a .NET Web Application, even though the process is clunky in places. So for now I have gone back to using a .NET Framework Web Application. I'm looking forward to seeing a fully mature version of ASP.NET Core Web Applications. It's not ready, but it looks very promising.
Related
Visual Studio 2019 template for Service Fabric has a drop down to select the dotnet framework. Mine only shows dotnet frameworks and not core. I am able to create other .net core application but not service fabric. Any ideas on what to look for? I have already validated the SDKs are on the computer.
OK, I think I understand what is happening. The first thing the template creates is the project. Since my development machine's OS is Windows, it requires me to use .Net framework. Once inside the project I am able to create individual .Net Core Applications. I haven't been able to find documentation that explains this. I was initially following this tutorial which seemed a little out of date or for some other reason was missing the step for setting up the projects framework version. I don't know how the projects framework is used in either case.
I'm familiar with the new deployment/installation design of VS 2017, and the way it leaves no footprint on registry.
And I'm also familiar with how we need to change our check-in policy installation from registry manipulation to VS extension creation.
However, now I need to create check-in policies in .NET Core 2.0. The problem is that I need to use Microsoft.TeamFoundation.VersionControl.Client dll to be able to access PolicyBase and also PendingChange classes. This results in FileNotFoundException.
Also I need to use Mono.Cecil as the reflection library, to be able to process things in more detail before checking-in. I can't find if Mono.Cecil supports .NET Core 2.0 or not. Nuget page is not informative and the libraries page on GitHub is also not easy to understand.
And another obstacle is to create a VS Extension. I can't find out the required package definition items to be added to source control.
Can you please provide a simple example of how to create a custom TFS Check-in Policy in VS 2017 via .NET Core 2.0?
Since the policy ends up running in the context of Visual Studio itself, I believe you have to be compatible with the .NET framework that Visual Studio is running in, and that is the "classic" .NET Framework, not .NET Core. Libraries written to a .NET Standard can potentially be consumed by both .NET Framework and .NET Core applications, and I believe you could also include separate executables in an extension and run them as separate processes if there's some piece that absolutely must run in a .NET Core environment, but you can't mix-and-match within a single process, and the extension code itself doesn't get a choice: it runs in the Visual Studio process.
.NET Core/Standard 2.0 now lets you reference old .NET Framework libraries. You can install them via NuGet, and the code will build. This works within limits though:
"The supported scenario is referencing a .NET Framework library that happens to only use types within the .NET Standard API set." -- Announcing .NET Core 2.0
When using Topshelf from a .NET Core 2.0 application, I get the following exception:
There seems to be a dependency on System.ServiceProcess.ServiceAccount that is not satisfied. Is this dependency available within the .NET Standard 2.0 spec at all? If not, is there any other way I can get this to work?
TopShelf does not work on .NET Core 2.0 because it is missing some other fundamental APIs as well (most prominent one would be ServiceBase). Some missing types are being developed as NuGet packages for the 2.1 timeframe but this does not mean that TopShelf is instantly going to work. You can follow TopShelf's GitHub issue for .NET Core support for details and updates and even some replacement libraries for basic functionality if you must run on .NET Core until TopShelf will be able to work on .NET Core (basis of which I have written).
I am building a project system for Visual Studio MVC web projects with controllers written in F#. It comes along pretty cool. I can build and run the apps, but I have a problem with FSharp Language Service.
In the editor it shows the syntax colorization and diagnostic as it should. With one problem - it does not pick up project references. Even though during build it picks them up and successfully builds the project, on the screen it shows the objects/namespaces from the referenced assemblies/projects as unresolved.
If somebody out here has some knowledge about integrating with F# Language service - please help me make it work
In response to Tomas:
The code for F# controllers is in the project file and as I already mentioned I can compile and run it. Originally we kept the F# code in a separate project and desire to get rid of this extra complexity is what prompted this project. It is not a ASP.MVC though it is Bistro MVC.
Edit
BistroMVC now solves this problem in the latest version of the Bistro Designer which is based on the F# project extender
Do you keep your F# source code as part of the Web Project? I'm not sure if this is even possible for ASP.NET MVC, but it was possible in ASP.NET WebForms. With WebForms projects, it didn't work very well (because F# wasn't aware of the project context). I believe it was possible to overcome this with a hacky #if like this:
#if EDITING
#r "Your.Referenced.Library.dll"
#endif
This would serve only as a hint to the editor... However it is much better idea (if it is possible) to write F# controllers in a separate F# project. In that case you shouldn't have any issues (at least I hope so!)
Can you describe what you're doing in more detail? Is this a "flavoring", or a new project system? Are other aspects of the 'project environment' picked up? For example, if you have F# code with
#if DEBUG
let x = 3
#else
let x = 4
#endif
does the coloring change when you change the VS solution from Debug to Release?
(Offhand I am unsure if it will be possible to fully integrate the F# language service into a user-defined project system; if you want more of a discussion, you can email fsbugs#microsoft.com and I'll respond there.)
I'm using Mono 2.4 on the Ubiquity web hosting service.
I created a simple MVC tutioal applciation, linked here, and verified that it worked using all Microsoft tools.
Next, the application was updated to point to a MySQL server database running on my Ubiquity host. The application works great on a Microsoft based machine.
Now, I am trying to deploy the application to the mono server on Ubiquity.
I set System.Web.MVC so it will CopyLocal=true.
I deployed the application to the mono server.
I get this error:
Description: Error parsing a resource required to service this request. Review your source file and modify it to fix this error.
Parser Error Message: Assembly System.Data.Entity, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 not found
Version information: Mono Version: 2.0.50727.1433; ASP.NET Version: 2.0.50727.1433
I am guessing the problem could be...
A) The Entity framework is not supported in mono. I need to use something other than the Microsoft Data Entity Framework.
B) The public key token for the mono version of System.Data.Entity is not "b77a5c561934e089".
C) There is something else going on.
I tried setting CopyLocal=true for the System.Entity.Data dll. Thus, the Microsoft version of the DLL deployed to my mono server. I have doubts that this is legal. At any rate, that only produced the following error:
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
Question
Can somebody confirm that it is possible to use the Microsoft Entity Framework on Mono? I am probably going to migrate away from the Microsoft Entity Framework, per this comment in the Microsoft MVC tutorial linked above..
"The ASP.NET MVC framework is not tied to the Microsoft Entity Framework. You can create >your database model classes by taking advantage of a variety of Object Relational Mapping >(OR/M) tools including LINQ to SQL, Subsonic, and NHibernate."
However, for the sake of consistency, I would like to use the Microsoft Entity Framework on mono if that is possible.
I can confirm that EntityFramework, Microsoft Chart Controls, and Microsoft Sync Framework do NOT work on mono on Linux, despite different claims from Microsoft and/or MS-employees.
That is because Sync Framwork uses pinvoke with a COM interop component, Microsoft Chart Controls has DirectorySeparator issues, and the EntityFramwork namespace is not ported to mono, yet.
So note that when Microsoft says "works with mono", they mean "with mono on Windows".
It is estimated that the EntityFramwork port will take 1 year at least, until it reaches alpha/beta stage, that is, if somebody would decide to do that.
But there are no official plans to port EntityFramework.
EntityFramwork might work/s on the windows version of mono, as long as you set localcopy to true.
I advise you to use nhibernate instead.
Update:
As of Mono 2.11.3, Microsoft has open sourced EntityFramework.
Hence, it is now a part of Mono's distribution.
This version comes with 349 commits, with around 514 file changes.
It includes 15553 insertions
and 3717 deletions.
Two down, one to go.
I guess this means:
BIG THANKS TO MICROSOFT, THAT 'S TERRIFIC ! ! !
You should set CopyLocal = true for the System.Data.Entity assembly as well. You noted that you copied System.Web.MVC local, but never mentioned that you copied System.Data.Entity locally. You might also need to copy local any of the assemblies that System.Data.Entity depends upon that are not part of Mono.
It looks like there is no support in Mono for EDF at the moment, but someone is working on it.