I've been looking into packing my WPF .Net Core 3.1 application into an MSIX installer using the packaging project.
However upon debugging or testing the output manually, the app crashes at launch due to it missing the Microsoft.EntityFrameworkCore.Design dll that my app is depending on. I can't quite understand why this is happening.
I do not reference this package directly, just the Microsoft.EntityFrameworkCore.Sqlite and Microsoft.EntityFrameworkCore.Tools packages, but when i do try to reference it directly, the behavior doesn't change.
I tried to follow this guide to setting it up for reference: https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/modernize-wpf-tutorial-5
I can see the dll is absent from the folder, is there something extra I need to do on top of this guide to get my app to run? The dll is provided in the build directory for the app itself, just not in the build directory for the package.
Any suggestions would be really helpful
So after fiddling with settings I discovered that the Microsoft.EntityFrameworkCore.Tools package which was referencing the Microsoft.EntityFrameworkCore.Design package that was missing had some properties blocking it from being included in the package projects output.
When pressing F4 on the EFC.Tools reference I found that its Private assets property was set to "all". Looking at the the documentation for this I can see that it would prevent the dll from passing to the package project where it would be needed.
Removing this attribute appears to have fixed everything. Considering though that it was a default setting, it would be helpful to know if this was the right solution however, feels more like a workaround to me.
Related
I have a web project that I'm trying to convert to Microsoft.NET.Sdk.Web. When I make the change to the .csproj file, though, it seems to force it to be interpreted as a <PackageReference>-based project. Of course, <PackageReference> isn't supported in web projects, because it doesn't support persisting the results of installing a package. Web projects must use packages.config in order to support NuGet packages that inject static content into the site's space (such as NewRelic). But, after switching to Microsoft.NET.Sdk.Web, the build system seems absolutely stuck on the project being <PackageReference>-based. How do I resolve this? Surely the very existence of Microsoft.NET.Sdk.Web implies that it is possible to use packages.config with an SDK project. But, even if I set <RestoreProjectStyle>Packages.config</RestoreProjectStyle>, it still thinks the project is <PackageReference>-based. I've seen advice to try running Update-Package -Reinstall after clearing out obj, bin and .vs, but nothing I've tried has convinced it that this is not a <PackageReference>-based project:
In Visual Studio, all of the NuGet-inserted references are lumped in with other references under Dependencies\Assemblies, and the "Installed" tab of the NuGet Package Manager is empty.
What do I do?
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.
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).
I'm creating a .NET Core xUnit test project library in VS2017. I accidentally installed the System.Collections.Immutable NuGet package, and now I want to uninstall it.
First, I tried editing the csproj file and removing this line:
<PackageReference Include="System.Collections.Immutable" Version="1.3.1" />
That didn't work, since the types from that package were still highlighted in the editor. So I tried running Uninstall-Package System.Collections.Immutable in the Package Manager Console.
The console said it couldn't find the package, so I tried putting the <PackageReference... line above back and running Uninstall-Package again. The console said the uninstall succeeded, but VS still recognized the types.
I tried closing VS, deleting .vs/, and reopening. It still recognized the types.
I tried git stashing my changes, running git clean -xdf, and running dotnet restore from the command line. Somehow, it still outputs
$ dotnet restore
Restoring packages for C:\cygwin64\home\james\Code\cs\BlockList\src\BlockList\BlockList.csproj...
Restoring packages for C:\cygwin64\home\james\Code\cs\BlockList\src\BlockList.Tests\BlockList.Tests.csproj...
...
Installing System.Collections.Immutable 1.2.0.
Installing System.Collections.Immutable 1.3.0.
...
I also tried restoring from Visual Studio instead of the command line. Still no luck.
When I searched all the files in my repo for the word Immutable, the only thing popping up is project.assets.json in the obj directory. Not a single source file contains the word Immutable. I'm confused, then, as to how it's still being referenced. How can I uninstall it?
A few other things:
I checked the 'Dependencies' drop-down for my project in Solution Explorer, and it's not listed there.
I don't want to delete my local copy of the repo and re-clone it, since I have other work stashed.
System.Collections.Immutable.dll doesn't show up at all in the bin/ directory, yet when I use one of the types in my library and run it, it works fine.
Thanks!
edit: Adding this line to the library:
System.Diagnostics.Debug.WriteLine(typeof(ImmutableArrayExtensions).GetTypeInfo().Assembly.Location);
And running it says that the assembly is located in this location:
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.1.2\System.Collections.Immutable.dll
After about an hour, I found out what the problem was. My .NET Core library referenced Microsoft.NETCore.App, which referenced System.Collections.Immutable. I looked at the dependencies for the former, but overlooked System.Collections.Immutable because that package references maybe 50 other packages. I ended up finding this out by creating a brand-new xUnit test project, and trying to see if ImmutableArray<> was present without installing anything. Sure enough, I could use it out of the box.
I had a similar issue with VS2017 and a different nuget package that wouldn't fully uninstall. I ultimately had to create a new project and cut and paste all my code into it. Kind of a sledge hammer approach, but faster than crawling through dependencies.
I'm having a particularly difficult refactoring session involving a C# solution with multiple projects in Visual Studio 2012. I needed to pull out a bunch of code into their own assemblies so that code could be shared across several projects, all in the same solution. However, no matter what I try, I get warnings for the projects that reference the new shared projects that "All projects referencing {shared project name} must install nuget package Microsoft.Bcl.Build".
I have been over the dependent projects and the shared projects with a fine-tooth comb, verifying in detail that they all use the same version and exact same DLL for the Microsoft.Bcl version 1.0.1.19 and Microsoft.Bcl.Async version 1.0.16 packages:
System.Runtime
System.Threading.Tasks
Microsoft.Threading.Task
Microsoft.Threading.Tasks.Extensions
Microsoft.Threading.Tasks.Extensions.Phone
The DLL paths are all resolved and identical. The XAP file does build but I still get that warning telling me that Microsoft.Bcl.Build is not referenced in the dependent projects, despite the fact that I can see that it is.
If I try instead to uninstall and then reinstall those two packages using NuGet for each project involved, I get references with empty paths and the warning icon for the 5 DLL references involved. For some reason NuGet adds the references but can't find the DLLs. Also, if I do this, I find myself with the problem frequently of having projects where I get the "Can't add reference" error when trying to add a reference. Then I have close and re-open the solution, and that leads to a "project failed to load" error. So I have to edit the project file manually, remove the faulty package import statements, and reload the project.
How can I fix this problem and what is the general technique for avoiding this headache in the future? Letting NuGet manage missing packages didn't help at al.
In case anyone else comes across this and #Swell's solution made you go "wtf":
I recently went through an older MVC project and updated it (updated razor, asp, http, etc. nuget packages). The project, independent of itself, built fine, but when i went to publish it failed with the OP's errors.
It turns out it's because I didn't update the *.Tests project associated with it (should have figured, though not sure why Tests is that closely tied to the project). So, to fix:
Right-click the Solution and manage nuget packages.
Go through all the packages that were updated in the web project and apply them to the other projects as well (each "Update" will display a tree with the applicable projects, I was fine just OKAY-clicking through).
Rebuild.
You should now be good and it shouldn't bark at you. Hope that helps others.
I just came throught the same issue and a bug is opened here: http://nuget.codeplex.com/workitem/3268
What I've done is the following, I added to the solution level the package Microsoft.Bcl.Build
In my dev env if you don't have the package loaded, just right click the solution and select manage nuget packages, you see a yellow bar with a restore button, just click it and you will be fine.
In my build script before compiling the project I run this command:
.\myproject\.nuget\NuGet.exe install .\myproject\.nuget\packages.config -OutputDirectory .\myproject\packages
This will restore solution level packages and you will be fine.
This should be fixed by the end of this summer in version 2.7 according to the issue report