I'm busy deploying a .NET Core 2.1 application into our testing environment, but I'm getting the following error.
Error:
An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found:
package: 'System.Diagnostics.EventLog', version: '4.5.0'
path: 'runtimes/win/lib/netcoreapp2.1/System.Diagnostics.EventLog.dll'
We are using the Windows Compatibility Pack to access the Event Log.
I have the following item in the dependency Json file:
"System.Diagnostics.EventLog/4.5.0": {
"dependencies": {
"Microsoft.Win32.Registry": "4.5.0",
"System.Security.Permissions": "4.5.0",
"System.Security.Principal.Windows": "4.5.0",
"System.Threading.AccessControl": "4.5.0"
},
"runtime": {
"lib/netstandard2.0/System.Diagnostics.EventLog.dll": {
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
},
"runtimeTargets": {
"runtimes/win/lib/netcoreapp2.0/System.Diagnostics.EventLog.dll": {
"rid": "win",
"assetType": "runtime",
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
}
}
Please advise how one should deploy these dependencies. Also, what is the root folder to this relative path runtimes/win/lib/netcoreapp2.0?
We actually found a solution for our scenario:
- Our situation was that we tried to run a netcoreapp based test project on our test agent
- dotnet test on the project file worked
- dotnet vstest sometimes worked on the project output directory (we are not sure why and on which setup)
- dotnet vstest did run into the above error when run into an other directory & downloaded from CI
- dotnet vstest did run into an AssemblyNotFoundException on the test agent (which didn't make any sense for us)
The solution was to use dotnet publish for our test project and use the "self-contained" output to run on the test agent. dotnet publish copied the required runtimes/win/lib/netcoreappX.X/*.dll files into the publish output directory.
After a lot of testing, the key issue seems to be the "RuntimeIdentifiers". There is a visible option for this when you publish, but in order to use it when just building you need to add a couple of tags to your .csproj file.
The first is:
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
This will cause NuGet to retrieve the correct dlls (change the value depending on your needs). For me I was compiling to platform x86. I don't know what NuGet was getting by default, but whatever it was had different file sizes for the same files.
You also should then add this tag:
<SelfContained>false</SelfContained>
or else your build will default to copying the entire framework.
Also note that using the RuntimeIdentifier tag will cause your default output folder to include the value you specified. For example my subfolder became:
Project\bin\x86\Debug\netcoreapp3.1\win-86\
For publishing you should be able to do something similar; the problem will be to match your RuntimeIdentifier to your platform. You shouldn't need to specify SelfContained unless you specifically need to.
Related
I have installed Robocorp Code as well as Robot Framework Language Server and have configured them. However, I am still having errors when trying to run the tests via the code lens options.
Repo - A webapi repo with a specific folder containing all tests. Lets call it regression.
RF - 4.1.3
Python - 3.8
This is what happens when I click on Run on the code lens for any of the tests -
`PS C:\git\xxxx\regression> C:; cd 'C:\git\xxxx\regression'; &
'C:\Users\xxxx\AppData\Local\Temp\rf-ls-run\run_env_00_smh5defr.bat'
'-u'
'c:\Users\xxxx.vscode\extensions\robocorp.robotframework-lsp-0.47.2\src\robotframework_debug_adapter\run_robot__main__.py'
'--port' '54331' '--no-debug' '--argumentfile'
'C:\git\xxxx\regression\args-local.txt' '--pythonpath'
'c:\git\xxxx\regression\common\lib' '--variable'
'EXECDIR:C:/git/xxxx/regression'
'--prerunmodifier=robotframework_debug_adapter.prerun_modifiers.FilteringTestsSuiteVisitor'
'c:\git\xxxx\regression\api\api_Test.robot'
[ ERROR ] Parsing'--pythonpath' failed: File or directory to execute does not exist.
However, the test starts if I remove the argumentfile parameter but it, of course, fails because its missing arguments from the file.
Do note that the folder specified in pythopath exists and has some python libraries needed for the tests.
I am getting this error when I use the -LockMode switch with the nuget restore command.
NU1004: The packages lock file is inconsistent with the project
dependencies so restore can't be run in locked mode. Disable the
RestoreLockedMode MSBuild property or pass an explicit
--force-evaluate option to run restore to update the lock file.
What I am trying to achieve is to automatically upgrade my nuget references by using wildcards but use specific versions when I want to re-build my project from known sources. this blog posts describes how this can be achieved Enable repeatable package restores using a lock file.
When I use -UseLockFile & -LockMode on a simple solution with just one project it works as expected, the issue arises when I start adding another project to the solution.
Here're the steps:
I have published my package to an Azure DevOps feed and I have the following versions listed:
1.0.1-ci.1
1.0.1-ci.2
I have created a .Net 3.1 console app that references my package using wild cards, i.e. <PackageReference Include="My.Package" Version="1.0.*-ci.*" />
Running the command nuget restore -UseLockFile -ForceEvaluate creates the packages.lock.json with the right reference (I am using -ForceEvaluate in order to ensure it always resolves to the latest version available on the feed), the contents of the lock file of my console project are:
{
"version": 1,
"dependencies": {
".NETCoreApp,Version=v3.1": {
"My.Package": {
"type": "Direct",
"requested": "[1.0.*-ci.*, )",
"resolved": "1.0.0-ci.2",
"contentHash": "4HQuN7LNoZT9Z+MOL/Yig79FehhXBZmi26j3VtWR9Cgz8k5irWspSQ8aasVbNkYp7AgA2XaDQdr/cnwJnPilpQ=="
}
}
}
}
I then publish a new version of My.Package (1.0.1-ci.3) and run the command nuget restore -LockedMode, and the version resolved is still 1.0.1-ci.2, and if I then run nuget restore -ForceEvaluate it will resolve as expected to 1.0.1-ci.3, so far so good!
The issue arises when I add a class library to my solution which uses the same package reference, i.e. <PackageReference Include="My.Package" Version="1.0.*-ci.*" />, when I run restore -UseLockFile -ForceEvaluate my packages.lock.json file is updated to include the project dependency:
{
"version": 1,
"dependencies": {
".NETCoreApp,Version=v3.1": {
"My.Package": {
"type": "Direct",
"requested": "[1.0.*-ci.*, )",
"resolved": "1.0.0-ci.3",
"contentHash": "4HQuN7LNoZT9Z+MOL/Yig79FehhXBZmi26j3VtWR9Cgz8k5irWspSQ8aasVbNkYp7AgA2XaDQdr/cnwJnPilpQ=="
},
"classlibrary1": {
"type": "Project",
"dependencies": {
"My.Package": "1.0.0-ci.0"
}
}
}
}
}
While the contents of the lock file of the Class Library project are:
{
"version": 1,
"dependencies": {
".NETCoreApp,Version=v3.1": {
"My.Package": {
"type": "Direct",
"requested": "[1.0.*-ci.*, )",
"resolved": "1.0.0-ci.3",
"contentHash": "4HQuN7LNoZT9Z+MOL/Yig79FehhXBZmi26j3VtWR9Cgz8k5irWspSQ8aasVbNkYp7AgA2XaDQdr/cnwJnPilpQ=="
}
}
}
}
After this when I try running restore -LockMode I get the NU1004 error mentioned earlier.
Doing what the error message suggests and use -ForceEvaluate would clearly break what I wanted to achieve, yet I can't imagine that this relatively simple scenario is not covered by NuGet, so I would guess I am doing something wrong, does anyone have any ideas of what I could try to make this work?
It sounds like you're adding a new dependency then running nuget restore -LockedMode without first running nuget restore -ForceEvaluate.
It's not obvious what NuGet should do in that case - you're telling it you only want to use the dependencies in your lock file but you've also added new dependencies too.
It sounds like this would typically fail the restore:
If locked mode is set, restore will either get the exact packages as listed in the lock file or fail if it cannot. For example, if you updated the defined package dependencies for the project after lock file was created
https://devblogs.microsoft.com/nuget/enable-repeatable-package-restores-using-a-lock-file/#why-use-a-lock-file
You might have hit a corner case if the only transitive dependency of your new dependency is one that's already in the lock file but at a different version.
In general though, whenever you add new dependencies you're going to need to update your lock file, then after that you should be set to carry on running nuget restore -LockedMode.
My goal is to deploy NuGet packages (to in-house Nuget server) that auto-increment the version based on date and last Rev, and include a -beta tag.
I am using VSTS to build and package using cake, with a build number format of $(BuildDefinitionName)_2.0.$(Date:yyMMdd)$(Rev:.r).
I have a .nuspec manifest file that specifies: $version$, and a NuGet Packager as such:
This works great. But now, I want to have the option of a NuGet packager that produces a package that is tagged as beta, and therefor show in VS NuGet Package Manager as pre-release. I can do this if I hard code the version number with "-beta" appended in the NuGet Packager:
But how can I include the -beta tag AND the the build number? I think I need to include a variable in NuGet Arguments that will return $(BuildDefinitionName)_2.0.$(Date:yyMMdd)$(Rev:.r) plus "-beta", but I'm not sure how.
I tried creating a variable (under the Variables tab) with the Build Number Format as the value, then referencing the variable in NuGet Arguments (-Version theVariable), but received as error that the variable is not supported.
I may be going about this all wrong, however my searches have not turned up any hints on how to auto-increment versions from the date, and include a -beta tag.
NuGet Packager with version using build number, adding -beta
I could reproduce your scenario on my side. In my opinion, Nuget pack task with build number doesn't support character or numbers. You may check this task:
case "byBuildNumber":
tl.debug("Getting version number from build number")
if(tl.getVariable("SYSTEM_HOSTTYPE") === "release")
{
tl.setResult(tl.TaskResult.Failed, tl.loc("Error_AutomaticallyVersionReleases"));
return;
}
let buildNumber: string = tl.getVariable("BUILD_BUILDNUMBER");
tl.debug(`Build number: ${buildNumber}`);
let versionRegex = /\d+\.\d+\.\d+(?:\.\d+)?/;
let versionMatches = buildNumber.match(versionRegex);
if (!versionMatches)
{
tl.setResult(tl.TaskResult.Failed, tl.loc("Error_NoVersionFoundInBuildNumber"));
return;
}
if (versionMatches.length > 1)
{
tl.warning(tl.loc("Warning_MoreThanOneVersionInBuildNumber"))
}
version = versionMatches[0];
break;
That is the reason why the field $(BuildDefinitionName) and beta could not appear in our package version when we use them in our build number.
If we specify the nuget version in the nuget arguments, but this argument could not parsing predefined variables, like $(Rev:.r).
The limitations of these two situations have caused your current issue.
The workaround to resolve this issue, is using nuget custom task with parameter -version $(Build.BuildNumber) and move the field $(BuildDefinitionName) from our Build number format, otherwise, we still receive the error the version is invalid.
So, you nuget custom looks like:
And the Build number format:
Now, you can see it works fine:
Note:
You said you using VSTS to build and package using cake, but the images you posted shows that you are using NuGet Packagertask in TFS 2015. If you are sure using TFS 2015, I am afraid above workaround will not work for you. Because the custom nuget task is not support for TFS 2015.
Hope this helps.
I'm unable to find some nuget packages (VS 2019, asp.net core 2.2). I found that System.ComponentModels.Annotations can't be found in my .nuget folder and in VS, there is no "expand" arrow next to it like all the other packages:
In my .nuget folder:
I've tried clearing out my packages folder and re-building to get all the packages. I've tried update-package -reinstall. I've tried Installing system.componentmodel.annotations directly (rather than having it install as a dependency). My solution builds fine, but I can't find this package anywhere on my harddrive. I've also noticed that Microsoft.AspNetCore.Razor.Design is exhibiting the exact same behavior.
When NuGet restores a project that uses PackageReference for packages (all SDK-style projects, and opt-in for traditional projects), it writes the obj\project.assets.json file, which is what MSBuild uses to complete the rest of the build.
Looking at the packageFolders section of my test project, I see this:
"packageFolders": {
"c:\\git\\test\\globalPackages\\": {},
"C:\\Program Files\\dotnet\\sdk\\NuGetFallbackFolder": {}
},
note that I have a nuget.config that redirects my global packages folder away from my user profile global packages folder, so temporary/fake packages I create don't pollute my real dev environment. FYI in case you're wondering why you don't see c:\users\zivkan\.nuget\packages.
But notice that there are two package folders.
Looking for System.ComonentModel.Annotations in the libraries section of project.assets.json, I see:
"System.ComponentModel.Annotations/4.5.0": {
"sha512": "UxYQ3FGUOtzJ7LfSdnYSFd7+oEv6M8NgUatatIN2HxNtDdlcvFAf+VIq4Of9cDMJEJC0aSRv/x898RYhB4Yppg==",
"type": "package",
"path": "system.componentmodel.annotations/4.5.0",
"files": [
// list of every file in package
]
},
see the path says system.componentmodel.annotations/4.5.0, which means it could be in either or both of c:\git\test\globalPackages\system.componentmodel.annotations\4.5.0 and/or C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.componentmodel.annotations\4.5.0.
For your use-case of trying to load it in Powershell, you can try to load one of the assemblies in the lib\* directory. Pick a TFM you think is compatible with your version of Powershell.
As for the reason that Solution Explorer doesn't have a twisty to expand the package, go find the package in the targets section of the project.assets.json and you'll see this:
"System.ComponentModel.Annotations/4.5.0": {
"type": "package",
"compile": {
"ref/netcoreapp2.0/_._": {}
},
"runtime": {
"lib/netcoreapp2.0/_._": {}
}
},
In other words, the package is not bringing in any assets or additional NuGet dependencies. Therefore nothing to expand in Solution Explorer.
In this specific case it's because netcoreapp2.0 has the assembly built-in to the runtime, and the Microsoft.NETCore.App package has the compile-time metadata for it. This is why I asked why you are looking for the package. If you use project.assets.json to find the exact System.ComponentModel.Annotations.dll that the build uses during compile, you'll find a metadata-only reference assembly that can't be loaded. But I gave insturations above on how to find the package directory and you can look for a loadable dll in one of the lib\* directories to try to load in Powershell.
I am trying to use NuGet to package and publish the package with TFS Build 2015 to local NuGet Server. I am getting error , I am not sure what am i missing. Thanks for Help.
Here is Error
Starting task: NuGet Packager
Set workingFolder to default: C:\Lucky\agent\tasks\NuGetPackager\0.1.58
Executing the powershell script: C:\Lucky\agent\tasks\NuGetPackager\0.1.58\NuGetPackager.ps1
Checking pattern is specified
No Pattern found in solution parameter.
Found files: 1
--File: "C:\Lucky\agent_work\1\s\Dev\FabrikamFiber.CallCenter"
The property DirectoryName does not exist or was not found.
Creating Nuget Arguments:
--ARGS: pack "C:\Lucky\agent_work\1\s\Dev\FabrikamFiber.CallCenter" -OutputDirectory "C:\Lucky\agent_work\1\s" -Properties Configuration=Release
Invoking nuget with pack "C:\Lucky\agent_work\1\s\Dev\FabrikamFiber.CallCenter" -OutputDirectory "C:\Lucky\agent_work\1\s" -Properties Configuration=Release on
C:\Lucky\agent\agent\worker\tools\NuGet.exe pack "C:\Lucky\agent_work\1\s\Dev\FabrikamFiber.CallCenter" -OutputDirectory "C:\Lucky\agent_work\1\s" -Properties Configuration=Release
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
Please specify a nuspec or project file to use.
Unexpected exit code 1 returned from tool NuGet.exe
Finishing task: NuGetPackager
Task NuGetPackager failed. This caused the job to fail. Look at the logs for the task for more details.
According to the error info:
Please specify a nuspec or project file to use. Unexpected exit code 1
returned from tool NuGet.exe
You may specified a wrong argument in nuget package task ,please double check you have followed below requirements:
Specify .csproj files (for example, **\*.csproj) for simple projects. In this case:
The packager compiles the .csproj files for packaging.
You must specify Configuration to Package (see below).
You do not have to check in a .nuspec file. If you do check one in, the packager honors its settings and replaces tokens such as $id$ and
$description$.
Specify .nuspec files (for example, **\*.nuspec) for more complex projects, such as multi-platform scenarios in which you need to
compile and package in separate steps. In this case:
The packager does not compile the .csproj files for packaging.
Each project is packaged only if it has a .nuspec file checked in.
The packager does not replace tokens in the .nuspec file (except the element, see Use build number to version package,
below). You must supply values for elements such as and
. The most common way to do this is to hardcode the
values in the .nuspec file.
Please double check your arguments , more details please refer this tutorial-- Pack NuGet packages.
Besides you could also enable verbose debug mode by adding system.debug=true to get a more detail build log info for troubleshooting.