I am attempting to work through the N+1 TipCalc tutorial & get the following error when trying to compile the core project:
Error 1 Metadata file '1\packages\MvvmCross.HotTuna.CrossCore.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.CrossCore.dll' could not be found C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC TipCalc.Core
Error 2 Metadata file '1\packages\MvvmCross.HotTuna.StarterPack.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.MvvmCross.dll' could not be found C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC TipCalc.Core
Error 3 Metadata file '1\packages\MvvmCross.HotTuna.CrossCore.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.MvvmCross.Localization.dll' could not be found C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC TipCalc.Core
NuGet 2.5 RC was installed from here https://nuget.codeplex.com/
Profile104 xml files created as per instructions & have been used for a few weeks with V3 prior to attempting to use NuGet for the MvvmCross components.
Pre NuGet TipCalc tutorial was accomplished without problems.
Downloading the complete project from GitHub also compiles without issues.
I haven't been able to see any difference between the packages.config file in the downloaded project and the project being created from scratch.
The profile of the core project is also the same in each case.
The dll's are at the location indicated.
There were no issues with using NuGet to download the package, only when attempting to compile the project.
Any suggestions as to what I have missed?
TIA
My guess is that the problem is in your path
The path seems to be C:\Source.CS\trunk\Learning\Mono\TipCalc1\TipCalc.N=1\TipCalc.Core\CSC
And the message is that '1\packages\MvvmCross.HotTuna.CrossCore.3.0.4\lib\portable-win+net45+MonoAndroid16+MonoTouch40+sl40+wp71\Cirrious.CrossCore.dll' could not be found
So maybe try using a path without an =?
Related
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 Restore step fails in my build definition with this error:
error NU1100: Unable to resolve 'AutoMapper (>= 6.2.2)' for '.NETCoreApp,Version=v2.0'.
This is in a .NETCoreApp 2.0 that is using AutoMapper. Restore succeeds locally in VS 2017. Locally I am using dotnet sdk 2.0.0, and nuget 4.3.1. On the VSTS (cloud) server, I am specifying the latest nuget version, 4.5.0. I have tried many other versions, including 4.3.1 with no success.
I know there is an older, similar question here, but that was never answered satisfactorily, in my opinion.
If I look at the meta data in VS, at the top of one of the Automapper files I can see this:
Assembly AutoMapper, Version=6.2.2.0, Culture=neutral, PublicKeyToken=be96cd2c38ef1005
// C:\Users\randyg.nuget\packages\automapper\6.2.2\lib\netstandard1.3\AutoMapper.dll
From this you can see it's taking the netstandard1.3 version, which is correct. I'm wondering if the nuget on the build server is looking for a netcoreApp2.0 folder, rather than the netstandard1.3 folder? Following this theory, I tried adding this to my .csproj file:
<AssetTargetFallback>$(AssetTargetFallback);netstandard1.3</AssetTargetFallback>
My theory was this would tell nuget to look for a netstandard1.3 version of automapper if it couldn't find a netcoreapp2.0 version. However, this didn't have any effect. I later read that behind the scenes this fallback is already added automatically.
If anyone has any ideas I would greatly appreciate it. I'm pulling out (what's left of) my hair on this, as this is the only package giving me trouble, and it's a critical one for my project.
On the build server I'm using .NET Core sdk 2.0.3 as well, if that matters.
This is how I solved this: since it seemed it might have to do with my target being netcoreapp2.0, I tried adding an additional 'dummy' project to my solution, with its target = netstandard1.3. In this configuration, the restore/build succeeded. I thought I would have to maintain this dummy project for this purpose, until I tried deleteing it and now the netcoreapp2.0 solution still restores fine without it. I can only assume something was corrupted in the TFS build server NPM cache (even though I had tried checking the box to disable that cache), and once I got it to succeed once, it has cleared up whatever the issue was.
I recently started experimenting with dot net core , and one of my major problems was restoring the dependencies. I went into the the project.json file and added some dependencies , the name was correct but the version was just trial and error until i reached the recent version. I couldn't seem to find any documentation online either , can anyone help me find or show me where i can find a proper list of all the dot net core dependencies and their latest version ?
I have used core to great success. The package manager in VS2015 and 2017 does a great job of resolving both the version you are using and other available versions. If you are working directly with project.json ( not available in VS2017, dependencies have been moved back to the project file ), it will only tell you what packages are available via your user cache. ( found in C:\Users\YourUserNameHere.nuget\packages for both vs2015 and 2017 ) by typing the package name and then letting intellisense do it's thing.
Of course once you do a get of a package it is then available from your cache.
I downloaded the TFSBranchTool VS Extension Project.
Rebuilt and Installed, but when I try to apply Initial Structure I get the following Error:
Exection Error:
Exection of Action 'ConnectSourceControl' Failed. Details: Could not load file or assembly Microsoft.AlLMRangers.BranchTool.SourceControlWrapper......
Any idea what might be causing the problem ? I tried on 2 different Servers! , I got the latest Update of VS2012.
I got VS2012 SDK installed and Vs2012 ObjectModel too, not sure what I'm missing!
We have posted an update to the sample code on http://vsarguidance.codeplex.com/releases/view/96222, which addresses this bug.
The issue was that Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll was missed in VSIX package. As action execution engine using MEF to load actions, it has no direct references to actions implementation assembly.
Vladimir from the team fixed the issue by specifying assembly as the MEF asset in the VS extension’s manifest file. Now it’s redistributed inside the extension package.
Can you verify that you have the file Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll
in the following folder:
%LOCALAPPDATA%\Microsoft\VisualStudio\11.0\Extensions\Microsoft. ALM Rangers\TfsBranchToolVSExtension\1.0
If its not there - try deleting the TfsBranchToolVSExtension and re-install the VSIX.
I have started with data nucleus a couple of days ago.
I have downloaded the jdo tutorial and am trying to run it.
I have collected all the jar files related to the tutorial here .
I am using ant for building. "compile" and "enhance" tasks work fine. The "createschema" task is spitting the following error out!
C:\datanucleus\datanucleus-samples-jdo-tutorial-3.0\build.xml:123:
taskdef clas
org.datanucleus.store.rdbms.SchemaToolTask
cannot be found
I have checked datanucleus-rdbms.jar for the SchemaToolTask and I didn't find that class in the jar file.
I downloaded it from here .
Why is that class not there?? Am I using the wrong jar file?
Why would you download 3.0 and use it with a tutorial for v 1.0?
In version 3.x the location of the SchemaToolTask changed from:
org.datanucleus.store.rdbms
to:
org.datanucleus.store.schema
reflecting the fact that the Schema tool is datastore agnostic.
Found that I was using source jar files instead of the binaries.
[Closing the question by marking this as the answer]