Apphost executable failed - c#

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.

Related

Unhandled Exception. Could not file or assembly "System Memory)

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).

Versioning Issue With Local NuGet Server Packages

Some background:
At my company, I have been working the last few months with converting our C# libraries to function on .dll references instead of project to project references. To do this, we have created a local NuGet server which contains NuGet packages for all of our libraries projects. We have Jenkins jobs set up for every project which build new NuGet packages and add them to the server every time a change is made to one of them.
For working on a single project, this system works great. You only have to worry about updating your packages folder through Visual Studio's NuGet manager, and then the rest is just writing code and building.
The issue:
When you add a new reference, or update your packages through NuGet, NuGet automatically specifies that specific version of the project that you selected in NuGet. With the current system I have setup, rebuilding a project locally will then replace it's .dll in the packages folder so that all projects that reference it can see these new changes you're testing. However, the issue come in that locally built projects have a different version than our Jenkins built packages. Our local builds use a different versioning system from our Jenkins builds so that you can easily tell whether something was built using Jenkins, or if some of the .dlls came from a developer's build. Because of this different versioning scheme, the reference of projects to the project breaks, because the new .dll that was built locally has a different version than the .dll that was retrieved from the NuGet server.
Current Solution:
For the moment, I have resolved this through the addition of a pre-build step. Before every project builds, the project calls one of my PowerShell scripts, which goes through and adds <SpecificVersion>False</SpecificVersion> to every project reference in the project being built's .csproj file. This resolves the issue, but only in the sense of putting a bandaid on it. Instead of dealing with the consequences of the system, I wanted to prevent them ahead of time so that this isn't needed every time a project builds. I have tried researching a lot about NuGet packages specific versioning issues, but have not been able to find anything online even remotely close to what I am asking. This makes me think that I'm going about this wrong.
The question:
What can I do to solve this issue? Or am I doing something very wrong and dumb that could be easily avoided by using another system? Any suggestions or tips would be greatly appreciated

one or more projects require a platform SDK(UAP, 10.0.16299.91)

I am trying to open the UWP project but however because of versioning issue I am not able to load the project. It gives me following error.
However, this version is already installed and even I have tried to install it again. But even after that is again giving me the same error.
I have updated the project version in .csproj file also as below. The version which is mentioned in the screenshot is already installed.
<TargetPlatformVersion>10.0.16299.91</TargetPlatformVersion>
<TargetPlatformMinVersion>10.0.16299.15</TargetPlatformMinVersion>
After doing all this it still gives the error as Visual Studio Update Required.
Any help on this appreciated!
Don't try to target your project to 10.0.16299.91 from your csproj, you can specific the target version to 10.0.16299.0 as Jet suggested. The build version is different from target version.
Thinking about this, if your customer is on 10.0.16299.0, then he cannot use your app? This is not reasonable. By the way, when you load your project, it will asks you to retarget your project, you can find the supported target version listed there.

Team Foundation Server won't build because nuget packages dont exist

So i created a new solution. Added all my projects to it. Downloaded all the nuget packages.
I checked it all in. On another pc I pulled the solution down. I hit build and I get a tonne of errors relating to not being able to find the dll of the packages.
So I set automatically download packages if they're missing. Still nothing works. Why is this?
When I Enabled it, it came back with an error saying that it could not modify the projects because they were locked.... This is why I want to re-enable the context menu item that allows me to enable nuget to automatically download missing packages.
I think the problem is I checked in all the packages. They all got download onto the other machine, that's why NuGet was saying that I already had the packages.
I solved this by going into the solution directory (physical path) and deleted the packages folder.
Then I built the project, and true to NuGets word it downloaded all the packages again. It also succeeded in building the application, no errors!
I would advise that if you are going to enable the NuGet package restore that you check out the solution first, once you're done check in the solution!

All projects referencing sub-project must install NuGet package Microsoft.Bcl.Build (C#/Windows Phone 7)?

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

Categories