I developing C#\XAML metro-ui application. I need some .NET types that doesn't included in .NET for Metro style apps or Windows references (for instance HttpUtility that is located in System.Web). I can't find System.Web via Assembly List. In same time I can refer it via Browse. But as I understand correct isn't it good way and I should avoid this, is it?
Next thing I have found description of Assembly Class. In the bottom of page in Version Information section I can see that it is supported by Portable Class Library. In the sample I see next code
Assembly assem = Assembly.GetExecutingAssembly();
But in my project Assembly doesn't have GetExecutingAssembly method. Is it documentation outdated? or I miss something?
I use Windows 8 Release Candidate and VS 2012
EDIT0: Instead of HttpUtility I should use WebUtility I know it. But I choose this type just for example.
EDIT1: I see public static System.Reflection.Assembly GetExecutingAssembly() via Object Browser but can't reach it.
Metro style apps can only call methods in the .NET Core Profile. You can see the Core Profile reference assemblies on Windows 8 RP machine at ...
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5
You can use ILDasm or ILSpy to view them. See A .NET developer's view of Windows 8 app development video from Build. He talks more about the Core Profile and why some classes, methods and interfaces were removed.
Related
I cannot find the dlls. Visual Studio does not tell you where they are stored. I want to load them into .net Reflector.
I know this is an old question, but if you're looking for these then check out the following location...
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App
Under there should be versions of .NET Core, and these are the runtime assemblies you'll need to load in Refelctor to see the source code.
Note - if you use an assembly reference from within Visual Studio (by maybe clicking F12 on a .NET Core datatype or interface), that will show the reference assembly and not the implementation assembly.
As an example, hitting F12 on ControllerBase gives me this...
C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\3.1.0\ref\netcoreapp3.1\
Microsoft.AspNetCore.Mvc.Core.dll
This is not the runtime assembly you need when using Reflector. GitHub is all fair and good for finding source code to one method, but you can't beat Reflector when you want to move between different classes in different files so as to work through an implementation pathway.
Hope this helps!
You can set them up I properties. They are still in the bin folder once the code is compiled. Although if you are planning on using the dll directly you can publish then first
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 am trying to create a class library that'll contain common objects (mainly DTOs) of a WebAPI (using ASP.NET 5) and a consuming UWP App. However, I have not yet figured out how to create the class library such that it can be referenced from both other projects.
What I have tried so far:
First, I tried a Class Library (Package), which can be found under Web. This type of library can be referenced from the ASP.NET project without problems, but when trying to reference it from the UWP project, I get the following message:
A reference to 'ClassLibrary1' could not be added.
Next, I tried a Class Library (Windows Universal), which can be found under Windows > Universal. This can easily be references from the UWP project, but when trying to reference it from ASP.NET, I get:
The following projects are not supported as references :
- The project ClassLibrary2 has a target framework that is incompatible or has version higher than the current project and cannot be referenced.
So: How can I create a class library that can be used in both an ASP.NET 5 project and an UWP project?
What you need is a Portable Class Library (under Windows).
Since you're only targetting ASP.NET 5 and Windows 10, you can limit the platforms to these two only, but there's no "error" in supporting more platforms (it can limit how much of the shared API is available though).
The .Net Standard class library should be thought of as a successor to the portable class library. Both aim to facilitate sharing code (in this case model objects/DTOs) between different .Net platforms.
In Visual Studio 2017, you can now choose a .Net Standard class library template. This class library can bet set to target different versions of the .Net Standard. The version of the .Net Standard that you should target will depend upon what .Net platforms you wish share code between.
For this particular question, we wish to support a Universal Windows Platform (UWP) app and Asp.Net Core app. So, we should refer to this compatibility table to determine the version of the .Net Standard that will support both of these platforms. In this case, it would be .Net Standard 1.4. Once you have set the class library to target the .Net Standard 1.4, you can add references to the class library from your UWP and Asp.Net core projects.
In order to better understand what the .Net Standard is and how it facilitates code sharing, I suggest reviewing the following:
Introducing .NET Standard
Video Series on .NET Standard (this is particularly good)
.Net Standard FAQ
I am in the process of writing a .NET wrapper for legacy native c++ code. My strategy is to write a CLR class library that wraps the native code.
To test whether the class library is functioning properly, I created two console apps in separate solutions:
A C++ CLR console app
A C# console app
Both of these contain the same simple test code to exercise the class library.
Both apps build as expected. The C++ app runs just fine, but the C# app is giving me a FileNotFoundException when it tries to load my class library.
I have a constraint that forces me to use VS2008 and .NET 3.5. Everything is built with Win32 or x86 configurations.
For both console apps, I am using a project reference to the class library.
In each case, builds copy the dll (and the intermediate files) to the same directory where each app is built.
I tried using the fusion log viewer, but logs are disabled on my machine and I do not have administrator privileges.
Has anyone ever seen this before?
Can someone please point me to a good site that outlines the differences between the way C# and C++ CLR apps load assemblies?
Since this is my first attempt to bridge C++ and C# I assume I am just making a simple mistake somewhere, but I am stumped as to what that is.
I have trolled the internet (including many SO postings) but have yet to find exactly what I need.
Thanks in advance,
Judd
I'm having a problem with assembly resolution on an end-user machine and I believe it's related to using Portable Class Libraries....
I have a .NET 4.0 application that was originally written in Visual Studio 2010. Recently we upgraded to Visual Studio 2012 and we've created a few projects that are Portable Class Libraries. I don't believe we need these features now, but we're also building a Windows 8 Store application that might benefit from these libraries.
When I compile my project, what exactly does the portable library feature do? I expect that it allows me to run it on different frameworks without modification or recompiling.
When I look at the library in reflector dotPeek it shows the Platform attribute as:
.NETPortable,Version=v4.0,Profile=Profile5
And the references seem 2.0-ish:
mscorlib, Version=2.0.5.0
System, Version=2.0.5.0
System.Runtime.Serialization, Version=2.0.5.0
When I run the application on this end-user's machine, I see an error in the log file:
Could not load file or assembly, 'System.Core, Version=2.0.5.0...'
Googling System.Core 2.0.5.0 seems to refer to SilverLight -- which appears to be one of the targeted frameworks.
This machine does not have Visual Studio installed, but has .NET 4.0 (4.0.3 update)
Is there something I should be doing differently to compile, something I should investigate in my dependencies or something I should be looking to install on the end-user machine? What does the 2.0.5.0 refer to?
For .NET 4, you need an update (KB2468871) for Portable Class Libraries to work. From the KB Article:
Feature 5
Changes to the support portable libraries. These changes include API
updates and binder modifications. This update enables the CLR to bind
successfully to portable libraries so that a single DLL can run on the
.NET Framework 4, on Silverlight, on Xbox, or on the Windows Phone.
This update adds public Silverlight APIs to the .NET Framework 4 in
the same location. The API signatures will remain consistent across
the platform. All modifications are 100 percent compatible and will
not break any existing code.
Also see the "Deploying A .NET Framework App" section of the MSDN Portable Class Library Documentation.
EDIT: Actually, if the machine has .NET 4.0.3 installed as you mention, that should be sufficient. Can you double-check to make sure that it is actually installed?