Yellow triangle over Frameworks\Microsoft.AspNetCore.App - visual-studio

I'm using VS2019 Pro v16.3.5. I have installed the .Net Core 3.0 SDK.
I have an Azure Durable Functions C# project that makes use of Microsoft.Extensions.Logging.Abstractions v3.0.0.0
This assembly is contained within the shared framework Microsoft.AspNetCore.App. So, I've added a reference to this from my csproj file, as seen below:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.0</TargetFramework>
<AzureFunctionsVersion>v3-preview</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
Trouble is VS seems to have difficulty resolving this. In Solution Explorer, for my project, I get a yellow triangle over Dependencies\Frameworks\Microsoft.AspNetCore.App:
I also get the following compilation error:
Could not load file or assembly
'Microsoft.Extensions.Logging.Abstractions, Version=3.0.0.0,
Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot
find the file specified.

I also had this issue after migrating to VS2019/netcore3.0
During migration I had to add a FrameworkReference to Microsoft.AspNetCore.App, just like Ruard pointed out.
In my case the solution was to :
close the solution
delete all bin/obj folder
(most important) delete the .vs folder.
Hope this will solve your problem as well.

Related

How do you get NuGet package restore to work on locally deployed packages stored in VSIX targeting Visual Studio 2019?

I am aware there are multiple questions on this topic already, but they all seem outdated. To clarify, I am using the "new" VSIX manifest format, and trying to follow the official instructions here: https://learn.microsoft.com/en-us/nuget/visual-studio-extensibility/visual-studio-templates
I have one project template and a couple of item templates that go with it. They all depend on deploying a NuGet package that should come bundled locally with the VSIX. I have examined the resulting VSIX file and all the files seem to be in the right place:
The project template has the required XML for declaring which packages to install:
<WizardExtension>
<Assembly>NuGet.VisualStudio.Interop, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</Assembly>
<FullClassName>NuGet.VisualStudio.TemplateWizard</FullClassName>
</WizardExtension>
<WizardData>
<packages repository="extension" repositoryId="VsixID.etc.etc">
<package id="Rx-Linq" version="2.2.5" />
</packages>
</WizardData>
The repositoryID matches the ID attribute in the .vsixmanifest file.
There is an individual Asset entry for each package, with the form:
<Asset Type="Rx-Linq.2.2.5.nupkg" d:Source="File" Path="Packages\Rx-Linq.2.2.5.nupkg" d:VsixSubPath="Packages" />
I have removed all packages.config and all the package references from the .csproj file installed by the VSIX (and even from the VSIX project itself just for good measure).
I have inspected the output VSIX and there is indeed a Packages folder in the VSIX containing all the .nupkg files. This folder is indeed unpacked and copied into the Visual Studio Extensions folder.
Despite all this, when I create a new project with the template, VS displays an error message saying: Failed to restore package from C:\users\<pathtoextensions>\Packages.
The thing is, the .nupkg files are actually present in the exact folder that the error message refers to.
I have been searching this for days and I can't seem to find any reference to best practices that actually work. It seems like these VSIX manifests are geared towards the legacy packages.config way of doing things, and there are discussions about how to extend them to use PackageReference instead.
Can anyone give any advice at all at how we are supposed to proceed going forward? Are packages not supposed to be deployed with the VSIX anymore? Are we supposed to just fill in the project with PackageReference entries and just let the user resolve them manually?
I feel like I am missing something fundamental here and any insight would be extremely valuable.
Update: I have also opened an issue on the NuGet github repository, as this is clearly a problem with the PackageRestore feature when restoring packages stored in a VSIX installer. Everything else mentioned in this question is working as intended and expected, except the package restore.
How do you actually include NuGet packages in Visual Studio Project
Templates VSIX targeting Visual Studio 2019?
Actually, there is no way to specify in a VS project template project that nuget packages can be used both using packages.config and PackageReference. Only two project templates of nuget management types can be created separately.
I have an easy way and since you have some issues with PackageReference format, you can try this funtion:
PackageReference
1) add these reference node in projecttemplate.csporj file:
<ItemGroup>
<PackageReference Include="Rx-Linq">
<Version>2.2.5</Version>
</PackageReference>
</ItemGroup>
2) When you create a project by this project template, please check these two options and VS will automatically read xxx.csproj and then recover the corresponding nuget package based on the information in it during build process.
Note: also make sure that the nuget url is checked and can be access under Package Source.
packages.config
In additon, for packages.config, you can just create a file named packages.config and then add your nuget info into it:
1)
2) add these into projecttemplate.csproj file:
<ItemGroup>
<Content Include="packages.config">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>
</ItemGroup>
<ItemGroup>
<Reference Include="Rx-Linq, Version=2.2.5, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
<HintPath>..\packages\Rx-Linq.2.2.5\lib\net472\xxxxxxx.dll</HintPath>
</Reference>
</ItemGroup>
Note: if this nuget package has dependencies, you should also add them(above steps) into packages.config and xxxx.csproj file. This funcution is a little more complicated than yours but it works. So, I recommend that you use PackageReference format.
More info you can refer to this similar issue.

Installing SQLite NuGet Package installs the package but the reference is not available. VS2019 Community

I"m writing a c# application using SQLite and I need the the SQLite Reference. Using NuGet I locate the package and the output window shows a successful install.
Looking at the packages config file in the solution explorer it shows the version installed.
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="SQLite" version="3.13.0" targetFramework="net472" />
</packages>
However under the project References in the Solution explorer SQLite is not there.
I have watched tutorials online where the same process is done on other machines and all is ok, all of the references pop up after NuGet finishes the installation.
I'm using VS2019 and from what I understand there were some changes on how NuGet operates, however I had VS2015 and VS2017 Community and had the same issues. I'm really at a standing point as I have no idea how to get the reference to show up so I can access it in my program.
SQLite has no Assembly reference so adding it there is not an option.
I have seen posts about a NuGet config file and Package Config File as well as the possibility of the package being installed outside of the Solution Folder but I don't know where. I have looked in the output location of the solution and none of the references are located in the debug folder anywhere.
I feel the Dll's are being installed outside of the solution folder but I don't know where and how to get Visual Studio to get them to the proper location or reference there existing location correctly.
Rebuild and Restore NuGet Packages provide no solution.
Any help would be greatly appreciated.
Installing SQLite NuGet Package installs the package but the reference
is not available. VS2019 Community
I assume you have installed sqlite version 3.13.0 nuget package.If so, it is the behavior of this nuget package. This package is very special in that it is a transactional SQL database engine that implements self-contained, serverless, zero-configuration.
In simple terms, it is a configuration function package that operates on related data when the project is running, rather than a package that provides a reference class library for the project.
Let me explain it in more detail:
This is the content of the nuget package sqlite version 3.13.0
Note that each folder provides specific functionality for the installation project.
And the function of the lib folder is to add its content(xxxx.dlls) as reference to a new project. In a word, Only the Dlls in lib folder can be recognized by nuget and added into Reference.
You can refer to this link for more detailed info about the function of the folders.
Second, there is a file called SQLite.props in the Build folder. The file will do some configuration to your project during build process.
In it, you can see these files:
<Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win7-x64\native\*">
<Link>x64\%(Filename)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<Visible>False</Visible>
</Content>
</ItemGroup>
<ItemGroup Condition=" (Exists('packages.config') Or Exists('packages.$(MSBuildProjectName).config')) And '$(Platform)' == 'x86'">
<Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win7-x86\native\*">
<Link>%(Filename)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<Visible>False</Visible>
</Content>
</ItemGroup>
<ItemGroup Condition=" (Exists('packages.config') Or Exists('packages.$(MSBuildProjectName).config')) And '$(Platform)' == 'x64'">
<Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win7-x64\native\*">
<Link>%(Filename)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<Visible>False</Visible>
</Content>
So when you build your project, the SQLite.props file will be executed and they will provide services during build or at the runtime.
All of these indicates it is a package for specific execution functions rather than a nuget package for adding reference libraries to the project.
Suggestion
As a suggestion, you could install System.Data.SQLite in your project. And this nuget package provides the dlls which you want in Reference.
Hope it could help you.

Visual Studio - Automatically include new files in project

I have a web app that generates some configuration files that I need to include into my VS-project. I know this can be done manually and also that there is a wildcard-solution (Auto include new files created outside Visual Studio) but I'm not really pleased with this.
I need the files to be included without having to reload the project, and also VS sometimes changes the wildcard configuration and reference the individual files.
I'm thinking that there might be some plugin etc that could to this? Something with a file system watcher that includes the files?
Or does anyone know how to prevent VS from changing the wildcard-config?
Edit: I think that the changed in the csproj are triggered when you ie add a new file to the project. Then VS removes the folder** and adds a direct reference to all the files included and to the new file.
Edit 2: Seems like this works until you remove a file from the solution explorer, that's when VS creates all these "hard" references to a file.
I came up with a solution that seems to work, that is importing an external project, in my YadaYada.Web.csproj:
<Import Project="..\CustomBuild.targets" />
And then in CustomBuild.targets
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Content Include="$(MSBuildProjectDirectory)\MyConfigurationFolder\**" />
</ItemGroup>
</Project>
This will included the files in my builds but not in the VS-ui which is probably fine for me.
Thanks!

Visual Studio relative path issue with non standard project extension

I'm trying to import a targets file from a relative path. The targets file is containing version information. The goal is not to have to modify all the thousands of projects files that we have when we create a new branch and have a new assembly version. We need the assembly versions because 2 version of the system can be installed at the same time and we have dlls in the global assembly cache.
Here's what it looks like in the project file:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\..\..\..\..\..\Versions.targets" />
...
<ItemGroup>
<Reference Include="MyDll, Version=$(VersionAssemblies), Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\..\..\..\..\..\..\..\..\Apps\$(CodeVersion)\DEVP\appl\BinApps\MyDll.dll</HintPath>
</Reference>
</ItemGroup>
...
</Project>
This is working fine if I'm working with a .vbproj. But the issue is that we have a lot of old .cobproj Cobol project files. For some reason, it seems like Visual Studio 2010 don't set the working directory when opening a cobproj, so it's unable to reach Versions.targets...
If I rename my cobproj to use vbproj as extension, it's working fine. So it's definitively something that Visual Studio is doing when a project of a known extension is opened, but I've searched a lot and I didn't find where I could add cobproj to tell Visual Studio that it's a known extension.
Another interesting fact, it that if I double click on my cobproj, it's working, because the working directory is already set to the directory in which the cobproj is... If I open Visual Studio and then do a File/Open and select my cobproj, then it's not working.
I'm wondering if someone may know how I could fix my issue without changing the extention of all my cobproj. I'd like a cleaner solution.
Thanks!
I've found a workaround, if I modify the Project Type Guid in the .sln, I can make Visual Studio act with my .cobproj like it would with a .vbproj, at least regarding the working directory setting.
From the .sln file:
Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "appsEXCI.Donnees.Containers.Cobol", "appsEXCI.Donnees.Containers.Cobol.cobproj", "{54E1DEC4-8919-40F6-B7BB-C936921B221F}"
EndProject

VS 2010: LNK1104 - cannot create import library

After porting a medium sized C/C++ application with a few libraries to VS 2010, I am getting the following error (Configuration: Debug, Platform: Win32):
LINK : fatal error LNK1104: cannot open file
'D:\projects\Libraries\SDL_image-1.2.7\VC10\Debug\Win32\SDL_image.lib'
I have quadruple checked SDL_net project settings in VS 2010. The folder name is correct, there are no folders containing blanks anywhere in the entire solution, etc. The DLL's object files are all in that folder (as they should be). Yet the import library cannot be created. This stuff works fine in VS 2008.
There are other similarly setup libraries in the solution (like SDL_mixer, SDL_net) and I don't have this problem with them.
How can I possibly fix this?
Check the vcxproj file - it seems like VS2010 adds reference to the project it self. I found following section at the end:
<ItemGroup>
<ProjectReference Include="XXXXXXXX.vcxproj">
<Project>{00e4326ce-9477-46e2-9133-43566aeec84e}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
Where XXXXX is the project name. After removing it everything went fine.

Resources