I'm working on an WASM app built with the Uno Platform, and have added a project reference that has been compiled and points to a DLL.
Now, when compiling, I get the error:
Error: Unhandled Exception: Could not resolve System.Text.Json (1, 1)
at Driver.Resolve(String asm_name, AssemblyKind& kind) (1, 1)
at Driver.Import(String ra, AssemblyKind kind) (1, 1)
...
What can I do to fix this?
According to Jerome Laban,
This is because there's no package reference to System.Text.Json now. If you add a reference to a dll instead of a project, this can happen because its own dependencies won't flow through.
Assembly dependencies are not supported by standard tooling. If you import a dll for which the dependency is not known, it won't work, you have to add an explicit package reference for that.
I've found that adding the missing nuget packages to the Wasm project directly fixes the issue (In my case,
adding System.Text.Json to StrixMusic.Wasm.csproj).
Related
The task is not practical, it's just learning experiment.
I have .net5 app (which essentially is asp .net core app) which references onto neighboring project "WebControllers" which contains only Controller class.
WebControllers is .net5 class library into which I added reference to Microsoft.AspNetCore.Mvc.Core package. This package allows to create of working Controller object which is discovered by asp .net core infrastructure and which properly handles http requests.
Now I want inside my WebController objec create variable of ApplicationPartAttribute type. I tried doing this like that:
var aaa = new Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPartAttribute("asd");
But Visual studio says to me that it don't know ApplicationPartAttribute class and it doesn't offer to use some namespace or add some package.
Let's go to the MSDN. MSDN about this type for .NET5 says:
Namespace: Microsoft.AspNetCore.Mvc.ApplicationParts
Assembly: Microsoft.AspNetCore.Mvc.Core.dll
Package: Microsoft.AspNetCore.App.Ref v5.0.0
Okay, let's try to install this package. Next errors are occured:
NU1213 The package Microsoft.AspNetCore.App.Ref 5.0.0 has a package
type DotnetPlatform that is incompatible with this project.
Package 'Microsoft.AspNetCore.App.Ref 5.0.0' has a package type
'DotnetPlatform' that is not supported by project 'WebControllers'
Why these errors are occured is unclear to me because both projects are .net5 projects and Microsoft.AspNetCore.App.Ref v5.0.0 is designed for .NET 5.
The question is: how can I use ApplicationPartAttribute in .net5 class library?
Add this code in your xxx.csproj file
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App"/>
</ItemGroup>
I am getting System.IO.FileNotFoundException in my .Net Core Web API. So I've set up the below project to demonstrate the problem.
I created a.Net Standard library named DemoLibrary and added QRCoder dependency via NuGet.
Disclaimer: Reason for choosing the QRCoder is that the Web API doesn't use it by default. I don't use it in my project. In fact, I'm getting this exception for EntityFrameworkCore.
I created a new .Net Core Web API DemoWebAPI which has no other dependencies.
Then added the DemoLibrary to DemoWebAPI via Add Reference -> Browse -> DemoLibrary.dll.
This is my solution:
The DemoMethod method in Calculate class just creates the object of QRCodeGenerator.
public class Calculate
{
public static string DemoMethod()
{
QRCodeGenerator qrGenerator = new QRCodeGenerator();
return "";
}
}
And my ValuesController in DemoWebAPI just calls the method:
[HttpGet]
public ActionResult<IEnumerable<string>> Get()
{
return new string[] { "value1", "value2", DemoLibrary.Calculate.DemoMethod() };
}
Now, when I run the DemoWebAPI project I get below exception upon the call to the DemoMethod:
System.IO.FileNotFoundException: 'Could not load file or assembly 'QRCoder, Version=1.3.5.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.'
I understand the fact that I have to copy the QRCoder.dll file somewhere. But I fail to understand where to put it. I've already tried putting it in "bin/debug/netcoreapp2.2" of the DemoWebAPI and "bin/debug/netstandard2.0" of the DemoLibrary.
But I couldn't get it working.
Request: Please post your answer as descriptive as you can because I am new to .Net Core.
Edit:
I am aware of the NuGet servers. I have read topics like hosting a NuGet server in IIS and Azure. The reason behind DLL reference is I want to use my DLLs in two projects one of them is a .net core API and the other is .net framework class library which is compiled by NMAKE. I couldn't find any way to restore NuGet packages in the .MAK files.
It looks like you've merely added the DLL for DemoLibrary to your DemoWebApi project. That's not how you should be adding references. Since these are in the same solution, you should add a project reference. That will fix your issue.
Now, let me explain what's actually going on here. Your DemoLibrary has a dependency on QRCoder. It's a NuGet reference, which means that package will be restored (i.e. downloaded) and included in your DemoLibrary build output. However, it will be included as one or more DLLs along side your DemoLibrary.dll. When you then just reference DemoLibrary.dll, you're missing all these other DLLs that are part of DemoLibrary and thus, things don't work properly.
Now, when it comes to a project reference, things are little more complex. A project reference essentially wraps the referenced project into your other project. You can think of it as sort of a sub project. For all intents and purposes, it's like any dependency of the sub project becomes a dependency of the main project. That means that DemoWebAPI now technically has a NuGet package reference to QRCoder even though there's no explicit package reference in its project file. The dependency comes from your DemoLibary project. As such, with a project reference, all the necessary dependencies will be included, because it's as if the main project included those itself, by way of the sub project.
For what it's worth, you should virtually never include a DLL as a reference directly. That used to be required, but the concept of NuGet packages has all but eliminated the practice. Even if DemoLibrary was not in the same solution as DemoWebAPI (meaning you could no longer do a project reference), the correct way to use it would be to turn DemoLibary into a NuGet package, and then reference it in DemoWebAPI via a package reference, like any other NuGet package. You do not simply add the DLL.
I have a solution which contains an asp.net 5 app, a code library, and a test library. The libraries are also the new project.json style. I am not really sure how to refer to these libraries to distinguish them from the existing library project structure.
Anyway, all three projects were targeting dnx451/net451. I decided to try targeting dnx46/net46. The libraries build, but the asp.net dnx app fails. The error is:
The design time host build failed with the following error: Object reference not set to an instance of an object.
It is referencing the file Microsoft.DNX.targets at line 166.
There is another error that just says, "Object reference not set to an instance of the object." It says line 1, but doesn't reference a file.
To test I created a new solution with and empty asp.net 5 project and 2 class libraries. I changed dnx451 to dnx46, and net451 to net46, and it compiles fine. I am not sure what in my existing project is causing this error, or where to start looking.
By the way, dnx46/net46 are the only frameworks targeted. I have removed the core frameworks.
What a load of trial and error. Turns out the issue was the razor precompilation module as described here, http://davidzych.com/view-compilation-in-aspnet-5-with-the-razorprecompilemodule/.
You can read the github issue here, https://github.com/aspnet/dnx/issues/3003.
I first tried to comment out the precompilation class. However just that fact that the file was there, made dnx throw the error. I removed the precomilation file and now it compiles fine.
EDIT:
Alternatively you can add dnx451 back into your project, along with dnx46 and then the precomilation module will work fine.
When trying to build a solution developed in VS2010, I get the following error in one of the subprojects that depends on a DLL built by another project in the solution, though it seems to have all the project references correctly interpreted by Xamarin Studio (v5.7.0).
/path/to/failing/project/myproject.csproj (Build) ->
/Library/Frameworks/Mono.framework/Versions/3.12.0/lib/mono/4.5/Microsoft.Common.targets (ResolveAssemblyReferences target) ->
/Library/Frameworks/Mono.framework/Versions/3.12.0/lib/mono/4.5/Microsoft.Common.targets: warning : Reference '/path/to/successful/parent/project/library/bin/ReleaseMac//mylibrary.dll' not resolved
After this error, there are subsequent compilation errors like:
The type or namespace name 'MyLibrary' could not be found. Are you missing an assembly reference?
These are presumably related to the fact that the DLL that did not resolve correctly contains that namespace.
Might this also be related to Xamarin not resolving references correctly?
I have a project which uses C++/CLI to implement a GUI and some background processing to talk to a sensor. I've got that all working and a lot of the comms stuff which we use to communicate the the sensor sits in a .dll. The problem is that I'd like to combine the library into the main executable to avoid having to worry about distributing .dlls.
I've got a demo project which works fine using a .lib but when I try and switch the mani code body to produce a .lib instead of .dll I get the following error:
1>------ Build started: Project: MyTool, Configuration: Debug Win32 ------
1>Compiling...
1>stdafx.cpp
1>.\stdafx.cpp : fatal error C1113: #using failed on 'c:\projects\MyTool\debug\MyLib.lib'
A bit of googling suggests this happens when you've not got the MSIL switch applied, but it's definitely in there in the library project.
I have a mixture of managed and unmanaged code in both my demo project and the real thing so I'm really struggling to see what the problem is here.
Any suggestions would be very gratefully received!
I am guessing a bit, but I suspect the "MyTool" project has the "MyLib" project as one of its "references" ("Project" menu >> Properties >> Common Properties >> References).
When you change the type of the MyLib project to a LIB instead of a DLL, you need to remove "MyLib" from the project references. You then update the project dependencies of the solution ("Project" menu >> "Project Dependencies...") so that MyTool depends on MyLib.
If you are linking to a mixed mode (managed/native) DLL you may get this error. Which you shouldn't if the project uses CLR even if one of the source files doesn't. But anyway, if that is the case, then try removing the reference from Project|Properties|Common Properties|References and then re-adding it.
I also ran into this. The reason it was failing was because I was compiling my native/managed C++ DLL to target .NET 4.0. And the DLL I was #using was a .NET 2.0 DLL. As such it was failing, even though the paths and file names lined up perfectly. In this case the error message was absolutely of no help at all.
I solve it by updating the independent DLL to .NET 4.0. So that both assemblies were using the same .NET framework.