What I'm trying to do:
Connecting HANA db from .Net Core application. (Windows environment)
What I did:
Downloaded and installed HANA Client for windows. Installed using "hdbinst.exe" from the folder "hdb_client_windows_x86_64" I got it.
Created a NuGet package for the file - "Sap.Data.Hana.Core.v2.1.dll" from the path: C:\Program Files\sap\hdbclient\dotnetcore\v2.1
Installed this file in to my sample .Net Core 2.1 project thru NuGet package manager.
What I'm experiencing:
Warning 1 -->
Warning NU1701. Package 'SAP.HANADBClient.NetCore 2.1.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.1'. This package may not be fully compatible with your project.
Warning 2 --> Warning MSB3270. There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\Users\XXXXX.nuget\packages\sap.hanadbclient.netcore\2.1.0\lib\Sap.Data.Hana.Core.v2.1.dll", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
Similar case for .Net Core 2.2 project
What I looked around:
I did a search in the web and saw few members had already shared this kind of issue (.Net core with HANA integration). But saw this post saying that the issue got resolved. But was it good? not sure.
Even this post says HANA supports .Net Core.
Did search in the web, but could not find the solution.
What I'm looking for:
Why am I getting these two warnings?
Will it give any issues later on - (prod runtime..)
Particularly - 2nd warning - why it's looking for "Processor architecture", and how to resolve this.
Can I request any one of you to help me out on this effort.
Please let me know still additional details are needed.
Thanks in advance.
To narrow down the issue, try adding the Sap.Data.Hana.Core.v2.1.dll library to your .NET Core 2.1 project directly (not through NuGet) and see if you get the compilation warnings.
If you don't get the warnings, then it's likely your NuGet package that's causing the issue.
If so, how did you create your package? If you created it using the SDK-style, check the TargetFramework to make sure it's set to the correct TFM or TxM as described here.
Also, according to this answer make sure you are using the correct version of the DLL, either x86 or x64.
Related
I have built a WPF project with .NET Framwork 4.8 and published it to Microsoft Store via a UWP bridge project as outlined here: https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-packaging-dot-net#prepare-your-application.
Basically, I had no problem following and publishing my .NET Framework project.
So, I decided to do the same with the same project as a .NET 5.0 project. However, when I select the final publish (right mouse click on the UWP project and then menu item publish - create app packages), in the resulting compilation I get the follwoing error:
There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\Projects......\bin\x86\Release\net5.0-windows\win-x86....dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. WapProjJHT_Inclusive C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 2183
I have built both projects targeting any CPU and have even tried just publishing a window's x64 target with the package and Always get this same error.
Does anybody know what could be causing the problem or if there is a better way to publish an MSIX package for upload the MS store? Thanks!
From the .NET APIs catalog, I understand that the Microsoft.Win32.Registry class is declared in the .NET Standard + Platform Extensions 2.0 package in an assembly Microsoft.Win32.Registry, Version=4.1.1.0, PublicKeyToken=b03f5f7f11d50a3a.
I've created a class library which targets .NET Standard 2.0, and here's a simple class:
public class NetStandardClass
{
public string GetHklmRegValue()
{
var lmKey = Microsoft.Win32.Registry.LocalMachine;
var softwareKey = lmKey.OpenSubKey("Software");
return "value";
}
}
I've created a .NET Framework 4.7.2 console application which references my above class library:
class Program
{
static void Main(string[] args)
{
string value = new ClassLibrary2.NetStandardClass().GetHklmRegValue();
}
}
When I run this on Windows, this throws a run-time exception:
System.IO.FileNotFoundException: 'Could not load file or assembly
'Microsoft.Win32.Registry, Version=4.1.3.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified.'
Based on what I've read, having assembly load issues in this scenario is somewhat of a known issue. The prescribed work-around is to enable automatic binding redirects and make sure my .NET Framework application is using PackageReference rather than Project.Config. I have done this with my projects from which I shared the above code, but I'm still getting the error. What confuses me most, though, is that the error is indicating the .NET Core / .NET Core + Platform Extensions assembly (Version=4.1.3.0, PublicKeyToken=b03f5f7f11d50a3a) rather than the .NET Standard (Version=4.1.1.0, PublicKeyToken=b03f5f7f11d50a3a) or .NET Framework (Version=4.0.0.0, PublicKeyToken=b77a5c561934e089) versions from the APIs catalog:
This is further corroborated by the Microsoft.Win32.Registry.DLL that is in the output directory:
Based on further reading, I can make a little progress by doing either of the following:
Add <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> to the .NET Standard class library proj file
-- or --
Add the Microsoft.Win32.Registry NuGet package directly to my .NET Framework console application.
Either of these results in loading some version of the assembly, but then I get some odd behavior: I get an NRE for the LocalMachine property, which shouldn't happen.
So here are the questions:
1.) Since my project is a .NET Framework application, why is it not using the Microsoft.Win32.Registry class in the .NET Framework API, specifically the mscorlib assembly that the same APIs catalog refers to?
2.) Why isn't the "work around" in the GitHub post not working for me?
3.) Why is it seemingly looking for the .NET Core / ... extensions version of the assembly?
4.) Why when I explicitly export the NuGet Microsoft.Win32.Registry assembly in the .NET Standard class library or directly reference the package in the .NET Framework console application does it result in the strange behavior where Microsoft.Win32.Registry.LocalMachine is null, which should never be the case on a Windows machine?
The following answers make an assumption of having the newest version of Visual Studio 2019 (v16.4.3 at time of writing) installed, as this may have some effect on the outcome.
Question 1):
1.) Since my project is a .NET Framework application, why is it not using the Microsoft.Win32.Registry class in the .NET Framework API, specifically the mscorlib assembly that the same APIs catalog refers to?
This will actually use the v4.0.0.0 mscorlib Registry class when the projects are set up in either of the following manners:
Option 1
Class library: Target Framework = netstandard2.0, NuGet packages = Microsoft.Windows.Registry (v4.5.0)
Console app: Target Framework = net472, NuGet is set to "packages.config" mode, NuGet packages = Microsoft.Windows.Registry (v4.5.0) [and also AccessControls and Principal.Windows, as they are dependencies]
NOTE: Here, if you don't add the Microsoft.Windows.Registry package, you typically will get the runtime error looking for version 4.1.1.0 of the Registry dll. But I believe the version it looks for is based on what the current .NET Core SDK version you have installed.
Option 2 [I think this is the one you really want]
Class library: Target Framework = netstandard2.0, NuGet packages = Microsoft.Windows.Registry (v4.5.0)
Console app: Target Framework = net472, NuGet is set to "PackageReference" mode, NuGet packages = None
NOTE: In VS2019, if you have the option for "Allow format selection on first package install" checked, then it will allow you to choose to use the PackageReference style, where NuGet packages are referenced in the project file instead of packages.config. Typically you have to install any one NuGet package just to set this mode, but afterward can uninstall that package and it will stay in that mode. I believe you could also set the default mode as well, before you first create your net472 project.
NOTE: Here, the PackageReference mode seems to help resolve the NuGet dependencies on the other .NET Standard 2.0 class library, where as the package.config mode requires you to do it yourself it seems.
This should be easily reproducible, however, things that can cause some sort issue can be any of:
- older versions of VS2019 being used
- skipping binding redirects setting turned on for NuGet in VS
- auto binding redirects turned off for the .NET 4.7.2 project
- not "rebuilding" the solution after package or reference changes
- not restarting the computer after installing/updating .NET SDK's or VS2019 updates
- still having a packages.config file
I'd also like to note that in Option 1 above, I found in testing this out that if you don't add the Microsoft.Windows.Registry package, it fails on runtime looking for version 4.1.1.0 of the registry dll. But, I was able to get it to fail looking for runtime 4.1.3.0 by first installing Microsoft.Windows.Registry 4.7.0, and then I uninstalled it (thereby leaving the two dependent packages AccessControl and Principal.Windows), and without rebuilding the project: if I run it, it fails on runtime with the 4.1.3.0 version being the one it's looking for. Rebuilding it reverts back to 4.1.1.0. This remains the same even if I remove the two dependent packages. Note: this also works if you simply remove the references to the dll's in the project, rather than uninstalling the NuGet packages.
Question 2):
2.) Why isn't the "work around" in the GitHub post not working for me?
I have a feeling this is happening because you may have an older version of VS2019 than 16.4.3. I found that when I was using an older version, the PackageReference mode still resulted in the runtime error. When I updated (sorry, I am not sure which exact revision actually fixes it) VS2019 to 16.4.3, this seems to now just work. I am not sure if this is some sort of unexpected interaction with the various SDK's (perhaps some being more recently released but not supported by an older revision of VS). It could also be an issue if the packages.config file is still lingering around.
Another issue could potentially be interference by other NuGet packages that may be installed and have different library version requirements.
Question 3):
3.) Why is it seemingly looking for the .NET Core / ... extensions version of the assembly?
In a .NET 4.7.2 project that references a .NET Standard 2.0 (.NET standard projects are .NET Core projects by default), it will utilize the .NET Core framework, not the .NET framework. So any references to the Registry are not by default available. You need the Microsoft.Windows.Registry packages (at the least) to allow use of the Registry, which I believe has the ability to act as a shim to the .NET 4.7.2 mscorlib verison of the library if available, but use the 4.1.1.0 version as a fallback (or 4.1.3.0 version if you're referencing from a .NET Core project instead).
Question 4):
4.) Why when I explicitly export the NuGet Microsoft.Win32.Registry assembly in the .NET Standard class library or directly reference the
package in the .NET Framework console application does it result in
the strange behavior where Microsoft.Win32.Registry.LocalMachine is
null, which should never be the case on a Windows machine?
I haven't personally tested this, and didn't run into this issue when I tested the above, but my feeling on this is that the dll's are likely missing their dependent dll's. But thinking about that further, would likely just result in another runtime error if that's the case. I think the issue is that they aren't intended to be directly exported and something may be missing along the way.
I'd also note that if you run this on any platform other than Windows, the registry is likely to come back as null since I think it wouldn't exist on, say, a Linux runtime.
Other Notes:
I get a general sense that this sort of thing has been a little buggy with VS and .NET Core in general referencing to/from .NET Framework, and that there's progress being made regularly to improve this.
I found also that there are some surprising issues I ran into that I didn't expect. For example, creating a .NET Standard console app, referencing the .NET Standard class library, and still getting the runtime error, no matter what packages I installed on the console app. You would think the exact same target framework would just work without any special configurations, but it doesn't seem to. But if you create a .NET Core console app instead, it does work properly. It's a bit mystifying, but there's always a technical explanation somewhere in the mix.
Using Visual Studio 2017 Enterprise, I'm trying to change the target framework on a unit test project to .NET Core so that I can use xUnit. I don't see it in the list of available frameworks.
In my list of available frameworks, I see:
.NET Framework 2.0 -> 4.7.1 and several Unity Frameworks.
This is despite the fact that I have .NET Core SDK 2.1.200 (x64), 2.1.202 (x64), and 2.1.500 (x64) installed.
It seems like you have 2 options, both of which are easy:
Change your target framework to netcoreapp*
Edit your project file and change
<TargetFramework>net461</TargetFramework>
to
<TargetFramework>netcoreapp2.1</TargetFramework>
(or whichever version of .NET Core you wish to target. SDK 2.1.500 is netcoreapp2.1 I believe.)
Use XUnit in a .NET Framework project
Create a .NET Framework class library project and install the xunit NuGet package. Then you can just start using XUnit like normal, and it can reference your web project.
To run test in VS, you'll also need the xunit.runner.visualstudio package.
Visual Studio only shows supported conversions. Converting from .NET Framework to .NET Core though isn't as simple as changing a version number.
You can use try-convert to make the necessary modifications to the project file. Make sure you use --diff-only first to inspect the changes.
You should check Nate McMaster's migration guide and Additions to the csproj format for .NET Core to understand the changes.
The tool isn't supported by Microsoft, nor is it guaranteed to perform a 100% conversion.
This tool is not supported in any way.
Who is this tool for?
This tool is for anyone looking to get a little help migrating their projects to .NET Core (or .NET SDK-style projects).
As the name suggests, this tool is not guaranteed to fully convert a project into a 100% working state. The tool is conservative and does as good of a job as it can to ensure that a converted project can still be loaded into Visual Studio and build. However, there are an enormous amount of factors that can result in a project that may not load or build that this tool explicitly does not cover. These include:
Complex, custom builds that you may have in your solution
API usage that is incompatible with .NET Core
Unsupported project types (such as Xamarin, WebForms, or WCF projects)
If the bulk of your codebase is generally capable of moving to .NET Core (such as lots of class libraries with no platform-specific code), then this tool should help quite a bit.
It is highly recommended that you use this tool on a project that is under source control.
Emphasis mine.
Why?
.NET Core and .NET Framework use very different csproj formats and handle package references differently, especially transient dependencies, ie packages that are needed by another package.
In .NET Framework packages.config contained all packages which means you had no idea which packages were really needed. In .NET Core there's no packages.config. The csproj files contains PackageReference elements only for the top-level dependencies.
In the old csproj format, you had to include every single source file explicitly. In the new format, all source files are included automatically, resulting in a file that's very easy to edit.
Making those changes isn't trivial. Until recently that was a manual process. Personally, I just removed everything, copied the minimal XML and added back package references until I got a succesful build. Even then, I had to manually add lines about included/excluded/copty-to-output files. If I had custom build steps with conditions etc, things would be a lot harder.
I have made a setup of Visual studio to compile C# code in my Ubuntu Machine .
I loaded the workspace/my code to VS and I could see the below error.
The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
Please help me on resolving this issue as am a beginner in Visual studio.
Thanks
If project is heavy, you can follow
this procedure
If your project is lightweight, create a new .netcore project using VS and move your code (and dependencies references)into that new project. then let VS telling you potential errors and correct them.
Looking at the procedure, you can firstly retargeting your actual project in dotnet 4.6.2 framework in order to "ensures that you can use API alternatives for .NET Framework-specific targets in the cases where .NET Core can't support a particular API."
I would recommend running the portability tool in Visual Studio 2017 if you have it. This will give you an idea if you will have a hard time moving it over.
As for your error with the csproj, that's because that file has paths within it, which are pointing to locations using windows paths, instead of Linux paths.
I just started to play around with C# application using the .NET framework.
I'm trying to install from Nuget the official neo4j driver package for c# but, despite the fact that from the documentation is stated that it should work with any version of .NET language (here), I got an incompatibility error from one of its dependencies (System.Net.NameResolution 4.0.0)
My application is a Console Application and the target framework is .NET framework 4.5.2.
In particular the error I get is:
Could not install package 'System.Net.NameResolution 4.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.5.2', 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.
Do you have any idea on how to solve this? I think I'm missing something obvious.
Thanks in advance
Your link states that it works with any .NET language not that it works with any version of the .NET framework. This package appears to be for dotnet core only, so you will need to look into getting started with that.