This is my first attempt at Q#. I followed the instructions here: How do I get the missing dependencies? Please see my screen shot
https://learn.microsoft.com/en-us/azure/quantum/install-command-line-qdk?tabs=tabid-vs
Have you tried just building the program? Nuget dependencies are typically downloaded the first time you build the program?
Looks like you're using the most recent version of the QDK (0.17.2105.144881), so you can open your .csproj file and confirm that it's using it. You should see this on the first line:
<Project Sdk="Microsoft.Quantum.Sdk/0.17.2105144881">
You can also confirm that the NuGet.config file in your machine has the public feed in it:
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
If you still get NuGet restore issues, I would also recommend installing .Net Core SDK 3.1.409 (Link). I see that you are using .Net 5.0, but you can have multiple versions side by side.
I hope this information is useful.
It seems like there is an issue with NuGet. If you in Visual Studio select Tools=>Nuget Package Manager=>Package Manager Console and in that write the command: dotnet restore.
And you then get an error similar to:
The package is missing the required nuspec file. Path:
C:\Users\x\.nuget\packages\x.x.x
Then there is something broken with your local NuGet cash, empty it by removing everything inside the packages folder. and then run the command dotnet restore again.
also includes the error messages, since image-texts isn't searchable (so that others also can find this):
No namespace with the name "Microsoft.Quantum.Canon" exists.
No namespace with the name "Microsoft.Quantum.Intrinsic" exists.
No type with the name "EntryPoint" exists in any of the open namespaces.
No identifier with the name "Message" exists. Assets file
'c:\User…\obj\project.assets.json' not fount. Run a Nuget package
restore to generate this file.
Related
I have a Azure pipeline with a MSIX Build and Package step for a WPF solution that started occasionally failing last week (with no changes to the pipeline definition) and is now failing every time with the error:
C:\Program Files\dotnet\sdk\5.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1004: Assets file 'D:\a\8\s\xxxxxx.Packager\obj\project.assets.json' not found. Run a NuGet package restore to generate this file. [D:\a\8\s\xxxxxx.Packager\xxxxxx.Packager.wapproj]
The project in question is the UWP packaging project and has no nuget references and I've had many runs of the pipeline which were successful.
The difference I can see in the logs is the failed builds (before the error above) seem to be missing a line:
Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Roslyn
I seem some other questions and answers around the error above but none specifically pointing to the issue above. The wapproj is included in the solution. Carrying out a nuget restore for the .wapproj does not fix the issue.
It's very odd that it was working and suddenly isn't with no changes to the pipeline.
First, you should make sure that you have add nuget restore task under pipeline. The restore should generate the guidance file project.assets.json file under obj folder. And that is necessary for build process.
And, you should moidfy your xxx.wapproj under azure repos and change Microsoft.Windows.SDK.BuildTools nuget package to version 10.0.18362.3-preview. From this document, the other versions are abandoned.
<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.18362.3-preview" PrivateAssets="all" />
I have a build pipeline configured for a Service Fabric solution on Azure DevOps like this:
Everything was fine until a few days ago when the build started failing on a particular build agent (private), with the following error (for a few projects):
C:\Program Files\dotnet\sdk\2.1.200\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(327,5): Error : Assets file 'F:\Agent03\w\84\s\src\MyProject.Sam.Tiles.Domain\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
The failing task is the Build solution $(PathToSolution) one.
The weird thing is that the build fails when running on some agents but with others the build is fine.
Some details:
Use NuGet 4.x task started using NuGet v4.9.1 very recently, I think. I tried using v4.8.1 with no luck;
Most of the projects use the PackageReference format, but the .sfproj project uses the packages.config file
I tried using the dotnet restore task but there is an error when trying to restore the packages for the .sfproj project:
`Error : Unable to find the
'....\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.props'
file. Please restore the
'Microsoft.VisualStudio.Azure.Fabric.MSBuild' Nuget package
Any idea on what might be causing this issue?
Some of the projects use the PackageReference format but the .sfproj project uses the packages.config file.
I still don't understand why the build started failing, but I was able to find a workaround. Given that PackageReference is not yet supported in Service Fabric projects, my workaround was to use both restore tasks as follows:
My problem turned out to be a solution that didn't include all the necessary projects.
I have a master solution file that includes all my projects, and a number of smaller solution files with only some of the projects. The master solution built fine in Azure DevOps, but the partial solution failed.
I realized that the missing project.assets.json file belonged to a project that needed to be included in this failing solution.
Trevor's comment on 2/20 gave me the clue. You likely don't have the complete set of projects referenced by the solution. (ProjectReferences may go to other projects, which are not in the solution).
Here is why this crazy workaround (run dotnet.exe and nuget.exe restore tasks) worked:
dotnet restore will walk project references by default to ensure they are restored also.
--no-dependencies switch can turn that off.
nuget.exe restore has the opposite default, because we didn't want to break old users.
-recursive can turn this on.
The right solution is to make your solution contain all the projects.
-Rob Relyea
NuGet Client Team, Engineering Manager
The error displayed during build:
error MSB4102: The value "" of the "Project" attribute in element is invalid. Parameter "path" cannot have zero length.
Reproduction steps are simple:
VS 2017 RC 2.
Create new Service Fabric Application targeting ASP.Net Core using Web API.
Then attempt to package the service fabric project.
I suspect there is a bug in Microsoft.VisualStudio.Azure.Fabric.ApplicationProject.targets that is part of VS 2017.
The one that sits in this directory: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\Service Fabric Tools
In the sdk targets file, there is this statement.
<PropertyGroup Condition="'$(LanguageTargets)' == ''">
<LanguageTargets Condition="'$(MSBuildProjectExtension)' == '.csproj'">$(MSBuildToolsPath)\Microsoft.CSharp.targets</LanguageTargets>
<LanguageTargets Condition="'$(MSBuildProjectExtension)' == '.vbproj'">$(MSBuildToolsPath)\Microsoft.VisualBasic.targets</LanguageTargets>
</PropertyGroup>
<!-- TODO: Generate error if LanguageTargets property isn't set here. This would happen, for example if an .fsproj referenced the .NET Sdk
but not the FSharp one. See https://github.com/dotnet/sdk/issues/448 -->
<Import Project="$(LanguageTargets)"/>
A little tough to decipher if you aren't used to it. But. In essence it is saying if it's a .csproj load the CSharp targets, if it is a .vbproj load the VB targets, if neither do nothing.
Then the next line tries to import the targets specified.
In the case of a Service Fabric project, that is a .sfproj, which means LanguageTargets is left blank and we get the error shown at the top of this post. The SF targets file should set LanguageTargets I think, before it reaches this line.
I suspect this sdk.targets file is some default template that hasn't been updated to handle VS 2017 service fabric projects yet.
Possible answer, but I don't like the idea of editing the Sdk.targets file installed by VS. Changing this line in Sdk.targets gets past this error, and doesn't cause any other errors in the build:
From: Matt Thalman at [https://social.msdn.microsoft.com/Forums/en-US/19fd8e9c-a517-4361-b50d-656d679d9c8b/visual-studio-2017-service-fabric-project-sdk-targets-error-when-packaging-sf-project?forum=AzureServiceFabric]
This issue should be fixed in the latest version of VS 2017 RC. Be sure you're running the latest.
However, even with the newest version, it is possible you can see this issue in cases where VS or some automated logic has downloaded the Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.4.0 NuGet package rather than using the package that ships in the box. The version of the NuGet package that ships in the box with VS 2017 RC has the fix for this issue. But the Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.4.0 NuGet package that exists in NuGet.org does not have the fix. There's currently an update to the NuGet package (version 1.4.1) containing a fix that exists but is unlisted. So if you need to make use of that updated package, you'll need to make some manual changes to your Service Fabric Application project:
Update the packages.config file so that it references version 1.4.1 of the Microsoft.VisualStudio.Azure.Fabric.MSBuild package.
Update your .sfproj file by replacing instances of "Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.4.0" with "Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.4.1".
Normally, NuGet would make the project file updates for you automatically when you update the NuGet package version but due to an issue that NuGet has with the Service Fabric Application project type, those updates do not happen automatically which is why you need to make these changes manually (and also why the package is defined as unlisted in NuGet.org).
Currently i am trying to build an autogenerating client on every time i release a new api.
I've got this running i can create the project and generate files from autorest.exe and everything works fine on my machine.
However when i try to replicate the same process on the buildserver i build my sln, and once i pack i get this error:
[pack] 'Microsoft.Rest.ClientRuntime' already has a dependency defined for 'Newtonsoft.Json'.
I have added this to my csproj file to pick up on the generated files, and this works fine on my local machine.
<Compile Include="Generated\*.cs" />
<Compile Include="Generated\Models\*.cs" />
I also tried including referenced projects on the build server like so
-IncludeReferencedProjects
After a couple of days im kind of stuck here, i have been having trouble finding docs on how to actually build the autorest generated client code, if anyone knows of some please share :)
Any help appreciated :)
The answer here was to update nuget on teamcity from 3.2.0 to 3.4.3 then the solution would build and run the files, i am still not sure what changed since this couldnt build, but somehow with 3.2.0 i had 2 references to newtonsoft within Microsoft.rest.clientruntime, when i updated it went away.
After many hours of searching, the answer was to run 'nuget update -self' on the failing copy of nuget.exe.
I have migrated my MSBuild-Integrated solution into Automatic Package Restore. It works on Visual Studio but when I try running the command
nuget restore Path/To/MySolution.sln
(I try doing that in my Package Manager console as well as in my Jenkins "Windows batch command" build step)
but in those cases I get an error The solution file has two projects named "1_2".
I cannot find these projects in my solution. Any ideas?
Sorry for not answering before but I ended up finding out that the solution had two websites created from the local IIS and they ended with a version number that was the same. Visual Studio named the project with this end only, which made this solution with two 'projects' with the same name. I could see it by looking in the sln file. Looks like VS does not treat this edge case :-/