What am I doing wrong here?
I have a DLL in .net Standard 2.0, and a console application, also in .net standard 2.0. The DLL is going to eventually be a custom nuget package for internal use by my dev team.
I installed System.Text.Json version 6.0.0 and I get the following runtime error:
"Could not load file or assembly 'System.Text.Json, Version=6.0.0.0".
I can see the nuget package in the location that Visual Studio 2022 is looking in.
Any thoughts on how I debug this?
I tried to explicitly install each of the dependencies, but that did not work.
***EDIT: I just realized that I no longer get that FileNotFound Exception if I explicitly copy that package's DLL into the console app's execution directory, but then I get a new FileNotFound exception for one of its dependencies. When I explicitly copy that DLL, I get another FileNotFound exception for the next dependency, and so on. I just assumed that the dependent nuget packages would get encapsulated in the dll that's using them. Copying each of the dependent DLL's is not really an acceptable solution.
After some investigation, I thought my issue might be related to:
Dependent DLLs of a NuGet package not copied to output folder
or related to:
MSBuild doesn't copy references (DLL files) if using project dependencies in solution
but that was not the case.
The output of my console app project was a DLL, even though it was clearly set to "Console Application". I just assumed that this was a new runtime method for VS2022, but that's not it. My console application Target was set to ".Net Standard 2.0", which is intended for DLL's. Once I set the Target to ".Net 6.0", everything worked as expected, and all the DLL's and packages were copied over correctly.
My DLL, which is being turned into a Nuget package, was properly set to ".net Standard 2.0".
Related
In my newly created BizTalk 2020 Dev environment when I'm adding a BizTalk Server Application Project (.btaproj) to the solution, the dialog window where you set the name of the project is showing the .NET framework selector and it defaults to version 4.7.2 as expected.
However when the project is added to the solution I can see in the properties for the project that it is targeting .NET 4.6.1. Has anyone seen this? is it a bug or something wrong with installation?
Naturally I change it to version 4.7.2 as the regular BizTalk project and everything compiles fine in Visual Studio.
But on our build server the same project fails. We use Azure Devops for CICD.On the build server we have the same version of VS installed (2019 enterprise) and BizTalk Server Extention (v3.12.1.0) is installed as well as msbuild tools from BizTalk server installation.
In the logs I first get a Warning:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3274: The primary reference "A.dll" could not be resolved because it was built against the ".NETFramework,Version=v4.7.2" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.6.1". [B.btaproj]*
And further down in the log the btaproj will not find the assemblies to include in the .zip package.
Message above implies that I have different target versions but I don't.
Now the strange thing is that I can log on to the build server and clone the same project and compile it with VS just fine.
The only way to make the build server compile the project successfully (or any other BizTalk project with .btaproj for that matter) is to change .NET to 4.6.1 (for both .btproj and .btaproj) and it all compiles nicely and deploys to BizTalk environment.
I have checked project files and files checked in to Git and everything seems OK with the sources files. The clean flag I set to clean sources and output directory. I Can compile a regular BizTalk project and .NET application with 4.7.2 on build server just fine it's only when I involve a .btaproj project where it starts to misbehave.
Can anyone point out where to start to look? the .btaproj seems fishy to begin with but it can also be isolated to the msbuild on build server and it differs from compiling with Visual Studio.
Since the BizTalk Server Application project e.g .btaproj defaults to target framework moniker 4.6.1 when added to the solution you will need to manually change the version manually for BOTH debug and release.
Do not get misled by the create project dialog where it defaults to version 4.7.2
As a workaround ,you can specify /p:TargetFrameworkVersion=v4.7.2 in the MSBuild Arguments column of the MSBuild task.
MSBuild lets you set properties on the command line by using the -property (or -p) switch. These global property values override property values that are set in the project file. This includes environment properties, but does not include reserved properties, which cannot be changed.
For details ,please refer to this document.
I have a .NET Standard 2.0 class library project with installed Nuget package System.Data.SqlClient version 4.4.0 and a Windows Form .NET Framework 4.7 project that has a reference to that class library.
Installing the Nuget Package and building the solution is successful. but in runtime every time that the code reaches a method that has any thing from SqlClient assembly inside it (for example an instance from SqlConnection) it gets this error:
Could not load file or assembly 'System.Data.SqlClient,
Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
Considering this question, I assume the problem was also there in the last major version of the Nuget package.
Edit
I downloaded the Nuget package and unzipped it and from \ref\netstandard2.0 folder copied the System.DataSqlClient.dll manually in \bin\Debug folder of my Windows Form Project and now it works. The exact situation also happened with Microsoft.Win32.Registry package. So I was almost convinced that it's my fault and I'm doing something the wrong way, but when I tested it with System.Drawing.Primitive Package it worked perfectly without any need to copy a dll. Now I'm really confused.
I guess you may have figured it out already but hope it would help someone - wasted some time too on this.
So, in order to make everything work you would need to reference System.Data.SqlClient in Windows Form project that is referencing your .NET Standard Library
From that point everything should be working like a charm
As you already mentioned System.Data.SqlClient.dll was not in output directory.
Sounds like .NET Standard Library haven't grabbed with itself dependent library binary. There is nothing like "Copy Local" option in .NET Standard references so I don't see any way to check or set this behavior too
I had same problem.
Solution for me was adding dependecy from nuget for latest System.Data.SqlClient at my .NET Standard Library project.
I had the same problem. The .NETStandard assembly was added as a reference to my WPF project. I needed to make changes in the .csproj of the WPF project.
The solution mentioned in https://github.com/dotnet/sdk/issues/901 fixes it.
Steps:
Edit your core .csproj file in notepad.
Add the below two lines in each that you find in it.
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
Clean and rebuild your solution.
I had a similar problem, bindingRedirect helped in my case:
<bindingRedirect oldVersion="0.0.0.0-4.4.0.0" newVersion="4.4.0.0"/>
I have a Powershell Tools for Visual Studio 2015 project that is a script module. I would like to add a project reference to a .NET 4.5 class library that is also a project in the same solution. From a visual perspective the dependency is listed under the references tree in the powershell project but it has the warning overlay icon on it. When running the pester tests they error out with a type resolution error (Cannot find type [IHE.Cda.TrifoliaParser]: verify that the assembly containing this type is loaded). I cannot find any documentation which indicates whether what I am attempting is even possible. Thus my question is whether it is possible or if the references list is just a artifact of being in visual studio.
Solution Explorer View
The References are an artifact of VisualStudio. It would be possible to generate an Import-Module <PathToThe>.dll line on top of every script in your project, but that's very obtrusive, and not every script will need all the dependencies.
What can I do to fix this build? Entity Framework was added to this project via NuGet.
All projects compile without issues on local system. But the build fails on Visual Studio Online.
By turning on Diagnostic logging, I am able to trace to this warning which makes my builds failed:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "EntityFramework.SqlServer". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
DO NOT right-click the project and chose "Enable NuGet Package Restore". This is the "old way" of doing package restores as per the Nuget Docs.
Package restoration should happen as part of the build process by default. If it's not (which seems to be the case), you've got a different problem, but there's not enough information to say what.
I am able to resolve this error simply by right clicking at the solution in Solution Explorer and select Enable NuGet Package Restore.
That adds a few more files to my solution and modify a few project files. The build server can then restore the packages at build time and is happy in the end.
I followed this blog post and I expected Nuget to just work. It obviously has not. I get errors on all of my third party dll's that I expect NuGet to update automatically:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\
Microsoft.WebApplication.targets (182): Could not copy the file "bin\AutoMapper.dll"
because it was not found.
I have set everything up correctly and I have ensured that the solution has Package restore enabled. If I delete a package locally and build, NuGet restores that package for me.
I am not sure why it is not fuctioning on the build server though.
Any Suggestions?
Try to add NugetRestore Activity to the TFS workfolw
Note:
For Team Foundation Build 2013 on-premises and Visual Studio Team Services (formerly Team Foundation Service), the default Build Process Templates already implement the NuGet Package Restore workflow without any special configuration.
I came across a similar error for log4net nuget package and I solved it in a different way. May be this will be useful to someone some day.
The error from TFS Team Build 2015
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\
Microsoft.WebApplication.targets (182): Could not copy the file "bin\Log4net.dll"
because it was not found.
Cause
The path to the nuget package in the .csproj file for referencing the package in the project cannot be found
Resolution
Edit the .csproj file of the project that has the error.
Look for the node ItemGroupin the .csproj file
You will see the HintPath pointing to a folder, most like the folder contain the name of solution as where it will file the DLL.
Replace the HintPath with <HintPath>..\..\Assemblies\3rd party\log4net\1.2.10.0\2.0\log4net.dll</HintPath>
You nuget package library may not be log4net but a different library. A very easy way would be to be edit the .csproj file of a project in the solution that contains the same nuget package library, copy the reference of the nuget in the ItemGroup and replace in the project that has the error. The reference should start contain ...\Assemblies\3rd party\ ... instead of a physical file location on your machine