After I included some .cs files from another project in my application when I publish my app and run it I get the following error.
My application is a windows form and the files I included are some kind of file parser in order to process a certain file type.
I have tried many times to rebuild and reload the project but the result is still the same. The target framework is .NET 4.8.
Does anybody has any idea on how to solve this issue?
That's because most probably, the code you inserted requires the presence of that dependency.
However, System.Memory is not part of the default framework, it's current version is 4.5.4 and it can be found on nuget.
If you use Visual Studio, you can conveniently add it to your Solution by using the Nuget Package Manager
You need to handle that dependency, either by installing the nuget package for your solution, or by directly downloading and providing the dll and its dependencies from the nuget site (not recommended).
Related
I am a dot net developer, i just updated my Vscode to the latest version and somewhat I am having issues building my web api project, Anytime I want to build any web api project it always pops an error
NETSDK1029; unable to use C:\Users\…….nuget
\packages\Microsoft.netcore.app.host.win-x64\6.0.13\runtimes\win-x64\native\apphost.exe
as application host executable as it does not contain the expected
placeholder byte sequence
I tried cleaning the solution and rebuilding it, I also downloaded latest SDK version all effort prove abortive
In cases like this, the first thing to do is clear the Nuget package cache. The easiest way to do that is to delete the contents of the C:\Users\…….nuget \packages folder, either the whole thing (safest) or just the subfolder for the offending package.
Then do a package restore from VS and see if it helps.
Am not experienced in C stacks, but am trying to build this DICOM project, it seems it's depending on a 'no-longer' existing project, so I tried to compile mdcm instead to generate the DLLs.
the generated dlls produce DICOM and Nlog, NLog didn't seem to work with the target project, missing classes etc ... when I installed Nlog version 1.0 using Nuget package manager the missing classes issues got solved but now I get the below error message.
what are possible solution to this ?
It means a dependency references a version of a package that is greater than the one you have installed into your app but your app reference will "win" since it is a direct reference, hence the error.
To fix it, you should install/upgrade to version 2 of NLog directly into your app although there might be build/runtime issues with that depending on the changes made in v2.
I'm looking for a simple way to manage NuGet packages for the whole solution, to prevent conflicts between transitive NuGet packages when assembling all files into one installer.
When building a project all direct and indirect dependencies are analyzed and the NuGet resolution picks up the best matching version for each NuGet that is at least the same version as the lowest version and might also create binding redirects if necessary. (all good and fine)
The problem we have lately encountered was when we build the whole solution (200+ projects) at once, the resulting NuGet versions between all top level projects might not be identical. And due to the fact, that all resulting DLL and EXE files are installed into the same program files folder, the application can and will crash at runtime due to version mismatches when loading assemblies.
To better understand this issue I've created this sample repo.
The dependency graph looks like this:
Library1
Microsoft.IdentityModel.Tokens-5.2.1
Executable1
System.IdentityModel.Tokens.Jwt-5.3.0 (transitive reference: Microsoft.IdentityModel.Tokens-5.3.0)
Library1
results in: Microsoft.IdentityModel.Tokens-5.3.0
Executable2
Microsoft.IdentityModel.Tokens-5.2.1
results in: Microsoft.IdentityModel.Tokens-5.2.1
To demonstrate the problem, all projects compile to the same bin folder. When the whole solution is compiled and Executable2 is started, the application crashes, since the application expects Microsoft.IdentityModel.Tokens in version 5.2.1 but the actual version is 5.3.0.
For this constructed sample it is easy to find the problem and fix it with updating the Microsoft.IdentityModel.Tokens NuGet to the same version. (Manually, since Visual Studio Package Manager does not recognize this conflict in the consolidate tab).
But at a much greater scale it is far more complex to find those mismatches.
What we have found so far
Centrally managing NuGet package versions
Since it is not yet available, it cannot be used to solve the issue here.
Microsoft.Build.CentralPackageVersions
Unfortunately there is no IDE support for it, which makes managing NuGet packages very uncomfortable, which I would like to avoid if possible.
So my question is what is the best approach to avoid NuGet version conflicts between projects within the same solution?
We've experienced the same problem with some of our projects. We've been using Paket package manager since a couple of years and this has resolved that issue for us.
In short: you define on your solution level which packages you want to use in a file called 'paket.dependencies'. You can be very specific about versions, or let packet use the latest greatest. Then you can specify per project which NuGet package you want to use within that project in a 'paket.references' file. As the name implies, you reference to a package in the paket.dependencies file.
This will make sure, all references packages in your project will use the same package version. I hope this suits your needs as well.
I have some trouble with running my project. When I try to run, the following error appears:
FileNotFoundException: Could not load file or assembly 'Dapper,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. The system cannot find the file specified
Context:
I have a Class Library X and a Web Application Y which have dependencies on X. When I try to run my API project, it throws the above error.
BUT, when my colleagues try to run the same API project, it works fine (no errors, and in /bin folder, it loads all the .dll libraries..)
I did those approaches:
Restart Visual Studio, clean and build a solution
Remove the class library references and add it again
Tools > Import and Export Settings Wizard > Reset all settings (maybe some setting was not well configured). I also tried to import colleague settings and didn't work either.
I tried various approaches(even in a different machine, but same VS settings) but none of these worked for me.
Visual studio 2019 16.4 Enterprise.
I'd also try:
1) Deleting your bin and obj folders in your solution before a rebuild.
2) Check that you've not got multiple versions of the same package across the solution (right click on solution in solution explorer -> manage nuget packages for solution).
3) Check that the properties of the reference (right click in solution explorer on the reference in question) shows a path to the package that you'd expect relative to the solution (eg not in mydocuments/nuget packages or something!).
4) Try a fresh clone of the repo (this should in effect replicate your co-workers' set up) and see if the problem still exists then.
I suppose another cause could be that your coworkers have a locally installed package / dll that they're happily referencing without realising, but you don't have?
When you copy a project from someone or another system, you need to download and install all components. normally VS will give you the option to "restore packages" when you load a newly imported from git but not sure if it does when you open an existing solution from a different system.
Right Click your project, Manage Nuget Packages
Browse -> Search for Dapper. Install
In the error you receieve, it tells you what version of the package should be installed as well. Installing a significantly different version might cause other unexpected errors.
thank you for your solutions but I found the problem:
The project solution has some projects with .net standard 2.0 and some with .net framework 4.8. Somehow, when I run the app, some packages are not loaded correctly and it throws an error.
That line below solved my problem:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Put it in all .net framework 4.8 projects on first XML tag.
Thank your for all.
Regards.
I had exactly the same Dapper error message today when referencing a .Net Standard 2.1 class library in a .Net Core 3.1 WinForm app. My resolution was to double-click the class library name in Solution Explorer to open the .csproj file, and then add a CopyLocalLockFileAssemblies tag to the PropertyGroup tag and setting it to true.
In my web and worker roles, I am referencing an alternative version of a core framework DLL. The file is marked Copy Local. Visual Studio shows the correct version in as a project reference. When compiling the project, the bin directory also contains the correct version.
However, when I ask Visual Studio to create an Azure package, the package (and the csx folder created during packaging) contains the wrong (original) DLL for the Worker role only. The Web role has the correct DLL. This does not occur if I manually use cspack, but that's not really a desirable way to package.
What could cause Visual Studio to compile with the correct reference DLL but bundle the wrong one?
Additional info:
When I run msbuild to do the packaging instead of Visual Studio, I see the following two lines:
Copying file from "C:\Users\bytenik\Dropbox\Treadmarks\lib\EntityFramework\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
Copying file from "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
So, it seems to copy my reference, and then copy over it with the system reference.
Note: I'm well aware that the entire concept of replacing a .NET CLR DLL is a huge hack. When .NET 4.5 comes out supporting the feature I need, this will all be stripped out. In the meantime, I need to be able to continue development.
This is a replacement to question "Azure References Incorrect DLL", which was actually factually incorrect and lead to answers that were valid, but did not solve my problem.
Even if a Visual Studio project has a reference to a local and/or modified copy of a assembly that is in the GAC, it will be used during the compilation, but at runtime, the CLR will always load the assembly from the GAC, even if it is sitting right there in the same directory as your application.
So the solution does not involve figuring out a clever way to pack or deploy the modified assembly, but figuring out a way of making the CLR actually load it if it's there.
Two possible solutions:
1) Use a role startup task and an installation project to deploy the modified version of the assembly in the production server's GAC.
2) Remove the signature of the assembly and make sure all references are made to this version without the signature. Beware other assemblies that may be referencing the original signed version and will try to load it from the GAC.
For more details and links see How to prevent a .NET application to use an assembly from the GAC?