Calling functions contained in a .NET Framework class library from Delphi has been solved long ago.
But we now have .NET Core and .NET Standard class libraries and would like know if using these in a Delphi project can be done. I'm not sure where to start or whether it is worth it. Obviously I can rebuild this library for .NET Framework but do I HAVE to do it this way?
Related
I'm building an ASP.NET MVC app with VS 2017, targeting .NET 4.7, and I'm trying to build my models inside of business library being referenced by the web application. So I'm trying to get many of the same classes that come with an MVC project by default into a brand new class library.
Particularly, I'm getting the following error:
This is very different from the previous times this question was posted:
The type or namespace name 'IClientValidatable' could not be found
The type or namespace name 'IClientValidatable' could not be found (are you missing a using directive or an assembly reference?)
Namely, in that they both are solved simply by including the using statement for System.Web.Mvc where IClientValidatable lives.
But I've definitely already done that... Here's the reference manager for the class library with the reference included available for .NET 4.7
As further proof, here's a side by side example of where I can pull in some classes from System.Web.Mvc, but not IClientValidatable
For reference sake, here's the configuration on the class library itself
So did this class move somewhere? Is it available with .NET 4.7?
So the real question seems to be not where did it go, but why the most recent framework is targeting such an old version.
When trying to add a reference to System.Web.MVC while targeting .NET Framework 4.7, the only available option is MVC v2.0.0.0 which is incredibly old. When seeding a new MVC app, it'll come with v5.2.3.0
Here's the Assembly Explorer with both libraries loaded. Common items will be highlighted in each, but IClientValidatable wasn't added until later.
And here's the VS 2017 Reference Manager where you can add references based on your current framework, showing the old MVC library for the new .NET version.
So the question then becomes....
Q: How can I add a reference that is not available in the list of assemblies for my framework?
A: Same way you'd add any other reference - you can browse to a dll or grab it from nuget.
DLL If you already have a web app, there are good odds you can find the dll in your existing packages directory at something like:
\packages\Microsoft.AspNet.Mvc.5.2.3\lib\net45\System.Web.Mvc.dll
If you prefer Nuget, some minor annoyances are that nuget package names don't exactly sync up with the assemblies they install, it's not easy to browse or search which assemblies come with which packages, and they libraries and frameworks often come bundled with other things you might not need. All that said, you'll be looking for the package called:
Microsoft.AspNet.Mvc on Nuget
Which will install the following libraries:
I have a Xamarin Forms solution, containing several F# portable class libraries.
In order to use the latest version (4.0.0) of Microsoft.Azure.MobileClient, I need to upgrade to FSharp.Core 4.2.1, but this appears to be incompatible with Profile 78:
Could not install package 'FSharp.Core 4.2.1'. You are trying to
install this package into a project that targets
'.NETPortable,Version=v4.5,Profile=Profile78', but the package does
not contain any assembly references or content files that are
compatible with that framework. For more information, contact the
package author.
It is possible to use .NET Standard class libraries from Xamarin projects, but is it possible to create a .NET Standard class library in F#?
What is the best way forward here?
What the error message is telling you is that the project is targeting a PCL target. FSharp.Core 4.2.x does not have a PCL target anymore, and only contains .NET Framework and .NET Standard 1.6 binaries. Neither is compatible with the PCL target F# is using here.
The release notes for FSharp.Core were recently updated with developer guidance: https://www.nuget.org/packages/FSharp.Core/
This is the important bit for your project:
For existing packages targeting .NET Frameworks 4.0 or lower and PCLs, use FSharp.Core 4.1 or lower.
.NET Standard (as of this time) has not proliferated across all things .NET yet. As #Foole says, you can indeed create a .NET Standard class library with F# today. But it's not compatible with the rest of the .NET ecosystem until .NET Standard is fully supported on all flavors of .NET.
You can try to convert your Xamarin.Forms (and your F#) project from .NET Portable to .NET Standard 2.0, since both packages can be added to .NET Standard.
How to convert Xamarin.Forms to .NET Standard
Create new Xamarin.Forms project (skip for already created project)
Create new .NET Standard library project in the same solution
Add reference to Xamarin.Forms package
Copy your content from Xamarin.Forms shared project to the new library project
Change all references (from Android, iOS, UWP) to point to the library project instead of the shared project
Source: Xamarin Blog
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.
How can a single .NET assembly, targeting 2.0, 3.0, 3.5, 4.0, and 4.5 concurrently, support extension methods for both C# and VB.NET consumers?
The standard suggestion is to add this:
namespace System.Runtime.CompilerServices
{
public sealed class ExtensionAttribute : Attribute { }
}
This the approach suggested by more than one Microsoft employee and was even featured in MSDN magazine. It's widely hailed by many bloggers as having 'no ill effects'.
Oh, except it will cause a compiler error from a VB.NET project targeting .NET 3.5 or higher.
The authors of Microsoft.Core.Scripting.dll figured it out, and changed 'public' to 'internal'.
namespace System.Runtime.CompilerServices
{
internal sealed class ExtensionAttribute : Attribute { }
}
Which seemed to solve the VB compatibility issue.
So I trustingly used that approach for the latest version (3.2.1) of the widely-used ImageResizing.Net library.
But then, we start getting this compiler error (original report), more or less randomly, for certain users targeting .NET 3.5+.
Error 5 Missing compiler required member
'System.Runtime.CompilerServices.ExtensionAttribute..ctor'
Because the MSBuild/VisualStudio compiler apparently doesn't bother to look at scoping rules when resolving naming conflicts, and the order of assembly references plays a not-quite-docuemented role, I don't fully understand why and when this happens.
There are a few hacky workarounds, like changing the assembly namespace, recreating the project file, deleting/readding System.Core, and fiddling with the target version of the .NET framework. Unfortunately, none of those workarounds are 100% (except aliasing, but that's an unacceptable pain).
How can I fix this while
Maintaining support for extension method use within the assembly,
Maintaining support for .NET 2.0/3.0
Not requiring multiple assemblies for each .NET framework version.
Or, is there a hotfix to make the compiler pay attention to scoping rules?
Related questions on SO that don't answer this question
C# Extension methods in .NET 2.0
Using Extension Methods with .NET Framework 2.0
strange warning about ExtensionAttribute
Ambigious reference for ExtensionAttribute when using Iron Python in Asp.Net
Should I support .NET 2.0?
Using extension methods in .NET 2.0?
We ran into the same issue with IronPython. http://devhawk.net/2008/10/21/the-fifth-assembly/
We ended up moving our custom version of ExtensionAttribute to its own assembly. That way, customers could choose between referencing our custom ExtensionAttribute assembly or System.Core - but never both!
The other tricky thing is that you have to always deploy the ExtensionAttribute assembly - even if you don't reference it in your project. Your project assemblies that expose extension methods will have an assemblyref to that custom ExtensionAttribute assembly, so CLR will get upset if it can't be found.
Given the hard requirement of .NET 2.0 support, I would think the best bet would be to simply not use extension methods at all. I'm not familiar with the ImageResizer project, but it sounds like this was a recent change in ImageResizer. How feasible would it be to change the extension methods to traditional static methods? We actually thought about that for IronPython/DLR, but it wasn't feasible (We were merged with LINQ at that point and LINQ had made heavy use of extension methods for essentially its entire existence).
I am working on an application in VS 2010 and using Asp.net framework 4.0 which i just migrated from Framework 3.5. The reason i had to migrate it to 4.0 is, i have a third party toolkit dll which is built in Framework 4.0, so in order to include it i had to change target framework of this project to 4.0. As, this project is being referred from other projects ans so on.., i end up converting whole application to framework 4.0. Every thing worked okay but as the application is using spring.net also, after successfully building the application, i found broken controls on almost all the pages. i am getting java script errors (about undefined control)for usercontrol PopupDatePickerControl we are using in the application. i downloaded and included latest version of Spring.net. i have no idea what is causing this problem. Please help if any one has experience working with this combination of framework 4.0 and spring.net? OR there is any way out to wrap up Framework 4.0 into 3.5. so i don't have to do this Migration.
Thanks!
Sounds like a shot in the dark on so many levels. It's probably not the combination of 4.0 and Spring.NET, unless you aren't referencing the correct Spring.NET dlls. Can you post parts of your IoC configuration and a rough outline of your app's architecture?
Also, what is the other third party toolkit you mentioned?