I am building an app that uses .NET Framework 4.5. One of the controls that I'm using is being flagged as an accessibility issue. That issue was fixed in .NET Framework 4.7.1, but I can't target a newer version now. Is there a workaround for this?
If you are unable to update your .NET Framework but want to take advantage of the accessibility improvements in the later versions, you can use Accessibility Switches to "configure your app to opt into accessibility features if it targets .NET Framework 4.7 or an earlier version but is running on .NET Framework 4.7.1 or later."
I am trying to understand the implications of starting a project on .NET core. One of the requirement I am facing is to use a .NET library that is leveraging COM.
So is COM supported by .NET core (obviously, assuming the OS is Windows)?
I understand that .NET Core is built for interoperability between different OS. But I was wondering if it is to be expected that there are Windows-specific features that may be included for the windows releases such as COM compatibility.
Thanks for your help.
.NET Core is developed to be cross platform and running also on Linux and Mac. COM is a windows specific thing and will not be supported in .NET Core
Need to embed a json file as a source for testing in my .NET Core application. The author of this post http://codeopinion.com/asp-net-core-embedded-resource/ provided sample code that included the use of var assembly = Assembly.GetExecutingAssembly();However when I try this I get the error: Cannot resolve symbol ‘GetExecutingAssembly’ and ‘Assembly’ does not contain a definition for ‘GetExecuringAssembly’
If you are targeting .NET Standard 1.5 or above, you may call any of the following:
System.Reflection.Assembly.GetExecutingAssembly();
System.Reflection.Assembly.GetEntryAssembly();
System.Reflection.Assembly.GetCallingAssembly();
If targeting earlier versions of .NET Standard then the typeof(SomeClass).GetTypeInfo().Assembly method is the only way.
There is no "static" Assembly class in .NET Standard prior to version 1.5. Instead you have to do something like:
typeof(<AClassHere>).GetTypeInfo().Assembly
Where <AClassHere> should be replaced by the name of a class/type in the assembly you wish to load.
Nope, it's not available in .NET Core 1.0/1.1.
However, if I remember correctly it will be back in .NET Core 2.0 and the netstandard2.0 which is to be released later this year, which will have a much bigger API surface and increased compatibility with libraries written against .NET >= 4.5 making it easier to port these to .NETStandard 2.0/2.1.
But many of the APIs implementations will be platform dependent. Means, you will be able to call SomeAPI.GetSomething() everywhere, but if run on .NET Core it may throw a PlatformNotSupportedException.
But most APIs about assembly scanning and discovering should be back in .NET Core/Standard 2.0. Stuff around AppDomain will still be missing as there are no AppDomains in .NET Core and processes should be used for isolation.
Our project structure is like,
native.dll :- This contains pure native code written in c\c++.
This native.dll exposes some functions using *def file.
Wrapper Library(wrapper.dll compiled with .Net framework v4.0) :-
In order to use functionality of native.dll, a Wrapper lib(wrapper.dll)
is written in C++\CLI using :clr\oldsyntax. This wrapper has all
code of Interoperability and Marshalling.
Application(Console App v4.0) directly uses wrapper.dll to use functionality provided
by native.dll.
Now this project needs to run in .Net Core. This means we will have an
.Net Core application that will reference wrapper.dll that in turn will refer
native.dll.
I know this will not directly work. But the issue is whether .Net Core(CoreCLR) supports
C++\CLI (clr\oldsyntax) runtime environment ?
If no, what can be the possible solutions to this application work ?
whether .Net Core(CoreCLR) supports C++\CLI (clr\oldsyntax) runtime environment ?
As far as I know there is no plan to support C++/CLI with .NET Core.
If no, what can be the possible solutions to this application work ?
You can (should) provide a C API. Mono e. g. supports P/Invoke and .NET Core also supports P/Invoke (see also this Stack overflow question and this DllMap related ticket).
Update (2022-09-02): This answer is from 2016. See the other answers (e.g., this) for what is possible with recent .Net Core versions.
Officially announced eventually...
(next wish... support linux # .Net 5 ^^)
https://devblogs.microsoft.com/cppblog/the-future-of-cpp-cli-and-dotnet-core-3/
C++/CLI will have full IDE support for targeting .NET Core 3.1 and higher. This support will include projects, IntelliSense, and mixed-mode debugging (IJW) on Windows. We don’t currently have plans for C++/CLI for targeting macOS or Linux. Additionally, compiling with “/clr:pure” and “/clr:safe” won’t be supported for .NET Core.
The first public previews for C++/CLI are right around the corner. Visual Studio 2019 16.4 Preview 1 includes an updated compiler with “/clr:netcore”
Updat: From replied of origin url:
"We are still working on the IDE and MSBuild integration, so I can’t share a sample project quite yet. Once it’s available, likely with 16.4 Preview 2 or 3"
(16.4 Preview1 cannot create C++/CLI with .NetCore project.)
191015
16.4 Preview2 Released.
I'v tried asp.net core 3.1 with c++/CLI dll, it works.
(need set plateform to x64 both asp.net core and c++/CLI dll)
.net Core team will only commit (now?) to supporting C++/CLI for Windows only.
The intention was to deliver it for .net Core 3.0. While I haven't found explicit mention of it yet in the release notes, C++/CLI support was a prerequisite for delivering WPF (windows-only), which is now supported in .net Core 3.0.
Support mixed-mode assemblies on Windows - #18013
This issue (#18013) will track progress toward supporting loading and running
mixed-mode assemblies on CoreCLR. The main goal is to provide support
for WPF and other existing C++/CLI code on .NET Core. Some of the work
will be dependent on updates to the MSVC compiler.
The github issue (#659) mentioned above by #Tomas-Kubes, Will CoreCLR support C++/CLI crossplat? - #659, is about cross-platform C++/CLI.
BTW, I am getting compiler warnings on "clr\oldsyntax" with VS2017/.net-4.7. So this compiler flag is already deprecated.
UPDATE: This isn't coming till .Net Core 3.1
Another potential solution (though obviously quite a difficult task) if you want to stick with C++ (i.e. expose an OO interface to .NET) might be to have a look at CppSharp from the mono project. It is able to expose native C++ code through an automatically generated C# wrapper. It supports Windows, Linux as well as OSX. However, I don't know if the generated code can be compiled to a .NET standard target (didn't try to). I can only suppose it would because the generated code does not use any fancy API (it is basically interop and marshalling code); and, by the way, it is also possible to customize the generation process (although, once again, probably not an easy task).
For those who are looking at this for general .Net Core stuff without specific clr parameters (as this is a high result on google) Microsoft have written a guide on how to port C++/CLI to .Net Core:
https://learn.microsoft.com/en-us/dotnet/core/porting/cpp-cli
Port a C++/CLI project
To port a C++/CLI project to .NET Core, make the following changes to the .vcxproj file. These migration steps differ from the steps needed for other project types because C++/CLI projects don't use SDK-style project files.
Replace <CLRSupport>true</CLRSupport> properties with <CLRSupport>NetCore</CLRSupport>. This property is often in configuration-specific property groups, so you may need to replace it in multiple places.
Replace <TargetFrameworkVersion> properties with <TargetFramework>netcoreapp3.1</TargetFramework>.
Remove any .NET Framework references (like <Reference Include="System" />). .NET Core SDK assemblies are automatically referenced when using <CLRSupport>NetCore</CLRSupport>.
Update API usage in .cpp files, as necessary, to remove APIs unavailable to .NET Core. Because C++/CLI projects tend to be fairly thin interop layers, there are often not many changes needed. You can use the .NET Portability Analyzer to identify unsupported .NET APIs used by C++/CLI binaries just as with purely managed binaries.
Build without MSBuild
It's also possible to build C++/CLI projects without using MSBuild. Follow these steps to build a C++/CLI project for .NET Core directly with cl.exe and link.exe:
When compiling, pass -clr:netcore to cl.exe.
Reference necessary .NET Core reference assemblies.
When linking, provide the .NET Core app host directory as a LibPath (so that ijwhost.lib can be found).
Copy ijwhost.dll (from the .NET Core app host directory) to the project's output directory.
Make sure a runtimeconfig.json file exists for the first component of the application that will run managed code. If the application has a managed entry point, a runtime.config file will be created and copied automatically. If the application has a native entry point, though, you need to create a runtimeconfig.json file for the first C++/CLI library to use the .NET Core runtime.
There are some more nuances but these are the actual steps to port
I've been working with the Portable Class Libaries using the Visual Studio 11 Beta release.
I've had quite a lot of success getting WP7, Silverlight and .Net 4.5 working together within "Profile104".
However, I've not found a way to get .Net 4 supported within the same or similar profile. In particular, I'm looking for a profile where System.Xml.Linq and System.Windows.Input.ICommand are available?
Is there any way to do this? Either by using a standard profile, or by creating my own profile and then adding type forwarding?
Thanks
Stuart
No, ICommand (as well as INotifyCollectionChanged and ObservableCollection) is not available in a portable library that targets a version of .NET before 4.0. We had to make some changes in .NET to support it (mainly adding System.Windows.dll with type forwards), which aren't available on earlier versions.
I believe System.Xml.Linq is available for portable libraries on .NET 4.0.3 and above.