Steps
Create a new .NETStandard 2.0 project e.g ClassLibrary1
Add xunit package as dependency
Open the command prompt and go to the location
Execute following two commands to create package
Please check dotnet pack for more details
dotnet build /p:SourceLinkCreate=true -v:n -c:Release -p:ci=true
dotnet pack -v:n -c=Release --no-build --include-source --include-symbols --output .\bin
Result: Package not created
Instead of xunit if you add any other dependency it works, for example NUnit and test framework, or Newtonsoft.Json. I have also tried with msbuild command, same result
Is there anything I am missing, or it's a bug?
This github issue says the behaviour is by design and your library needs the IsPackable setting in .csproj:
<Project Sdk="Microsoft.NET.Sdk.Web" ToolsVersion="15.0">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsPackable>true</IsPackable>
...
Related
I am scaffolding a local login identity page in into a asp.net core solution that already has default identity. I am doing this in order to customize my login page.
I have successfully done this using two test apps which use the same base code with progressively more packages installed) before attempting this on my final.
For my app, when I issue the following command, I'm getting this error:
PM> dotnet-aspnet-codegenerator identity --dbContext ApplicationDbContext
Failed to get Project Context for C:\Users\...\rollbase.csproj.
To see more information, enable tracing by setting environment variable 'codegen_trace' = 1
There is no information about 'codegen_trace' in docs.
I have searched and found a lot of references to this error. But can't find anything for:
What is the 'Project Context'
How do I use a 'codegen_trace'
The solution builds successfully.
I have been very careful keeping track of the packages involved
Microsoft.VisualStudio.Web.CodeGeneration.Design
Microsoft.AspNetCore.Identity.EntityFrameworkCore
Microsoft.AspNetCore.Identity.UI
Azure.Identity
Using
<TargetFramework>net5.0</TargetFramework>
dotnet-aspnet-codegenerator' (version '5.0.0')
dotnet sdk 5.0.403
Microsoft.NETCore.App 5.0.12
Most posts talk of rolling back the tool version/packages etc. I was wanting to know if anyone out there can actually point to a solid debug strategy.
I am adding info to this question below
Using help provided - output from codegen_trace
Microsoft.Extensions.ProjectModel.MsBuildProjectContextBuilder.Build()
/_/src/Ext.ProjectModel.MsBuild.Sources/MsBuildProjectContextBuilder.cs:line 56
At Microsoft.VisualStudio.Web.CodeGeneration.Tools.Program
.GetProjectInformation(String projectPath, String configuration) in
/_/src/dotnet-aspnet-codegenerator/Program.cs:line 290
At Microsoft.VisualStudio.Web.CodeGeneration.Tools.Program
.BuildAndDispatchDependencyCommand(String[] args,
String projectPath, String buildBasePath, String configuration, Boolean noBuild, ILogger logger)
in /_/src/dotnet-aspnet-codegenerator/Program.cs:line 173
Microsoft.VisualStudio.Web.CodeGeneration.Tools.Program
.<>c__DisplayClass19_0.<Execute>b__0() in
/_/src/dotnet-aspnet-codegenerator/Program.cs:line 129
From this output it looks like a problem in the installed package Microsoft.VisualStudio.Web.CodeGeneration.Tools 5.0.2
I have tried to update the package to 6.0,0 in Visual Studio 2019 (latest) but get the following:
NU1202: Package Microsoft.VisualStudio.Web.CodeGeneration.Design 6.0.0 is not compatible with net5.0 (.NETCoreApp,Version=v5.0). Package Microsoft.VisualStudio.Web.CodeGeneration.Design 6.0.0 supports: net6.0 (.NETCoreApp,Version=v6.0)
I looked at the github repo for this project but could not find any documentation regarding compatibility with .NETCoreApp,Version=v5.0
With reference to the original error message:
PM> dotnet-aspnet-codegenerator identity --dbContext ApplicationDbContext
Failed to get Project Context for C:\Users\...\rollbase.csproj
I have compared the .csproj files for the project where codegenerator works against the one where codegenerator fails to get Project Context.
The main difference is in the Property Group.
The codegnerator works:
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<UserSecretsId>aspnet-testbase1-57C4221E-46E9-4653-A734-4C412F7C523D</UserSecretsId>
</PropertyGroup>
Where Project Context not found:
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<UserSecretsId>aspnet-rollbase-6D7D2449-EB25-45CE-A8D3-EDAB69CDCAB3</UserSecretsId>
<RootNamespace></RootNamespace>
<RunAnalyzersDuringBuild>false</RunAnalyzersDuringBuild>
<AssemblyName />
<PackageId />
<EnableNETAnalyzers>false</EnableNETAnalyzers>
</PropertyGroup>
The best way to understanding the codegen_trace environment variable and it's output is reading the source code.
To enable the Trace logs, set the codegen_trace environment variable before you run dotnet-aspnet-codegenerator:
Command Prompt
SET codegen_trace=1
PowerShell
$env:codegen_trace=1
Bash/Zsh/Fish
export codegen_trace=1
The Project Context means the context of the project information. Most of the project information included in *.csproj file. Your problem is very possible that your project can't build successfully. You have to make sure your project is buildable.
For your dotnet-aspnet-codegenerator identity --dbContext ApplicationDbContext command, you at least need to install the following packages to get things right.
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.AspNetCore.Identity.UI
dotnet add package Microsoft.VisualStudio.Web.CodeGeneration.Design
Please check the version of your code generator CLI tool version is the same as with your.NET version. You need to set the codegen_trace as an Environmental variable like this if you're in Linux or mac
codegen_trace=1
If you're using Powershell you can set it like this.
$env:codegen_trace=1
There is a GitHub open issue related to this. Please check the solutions on that as well. - https://github.com/dotnet/Scaffolding/issues/1388
I edited the project file PropertyGroup section. From what it was (see additional info in question above) to:
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<UserSecretsId>aspnet-rollbase-6D7D2449-EB25-45CE-A8D3-EDAB69CDCAB3</UserSecretsId>
</PropertyGroup>
Identity files were scaffolded using:
dotnet-aspnet-codegenerator identity --dbContext ApplicationDbContext
[Trace]: Command Line: identity --dbContext ApplicationDbContext
Building project ...
[Trace]: Command Line: --no-dispatch --port-number 52819 identity --dbContext ApplicationDbContext --dispatcher-version 5.0.0+a93dad81ee7f820d8e33d3f91e066ef68053d004
Finding the generator 'identity'...
Running the generator 'identity'...
...etc...
I'm trying to figure out how to specify a packageId at build or specifically at package time. I have the following in my csproj which works well for creating packages locally for the purposes of testing. We are using Azure DevOps build pipelines to build and pack our nuget packages and I would like to be able to set the packageId as a task or msbuild parameter within the build pipeline.
Does anyone have suggestions on how I could acheive this?
Thanks,
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);Dependencies</TargetsForTfmSpecificBuildOutput>
<Version>0.1.0.5</Version>
<PackageRequireLicenseAcceptance>true</PackageRequireLicenseAcceptance>
<AssemblyName>MyAssembly</AssemblyName>
<RootNamespace>MyAssembly</RootNamespace>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<PackageId>MyAssembly.Test</PackageId> <----- set at package time
<FileVersion>1.0.0.0</FileVersion>
<PackageLicenseUrl>https://my.domain.xyz/license.pdf</PackageLicenseUrl>
<AppxAutoIncrementPackageRevision>True</AppxAutoIncrementPackageRevision>
<Description>A useful description.</Description>
<Company>XYZ</Company>
<Authors>UiPath</Authors>
<PackageIconUrl>http://my.domain.xyz/favicon.ico</PackageIconUrl>
Set PackageId at package time?
The answer is yes.
According to the document MSBuild pack target inputs, we could to know the PackageId is supported to be set at build time.
Note:
I saw that you set the property GeneratePackageOnBuild to true, so visual studio will generate the nuget package automatically.
So, if you are not use extra dotnet pack task to package your package, you add msbuild argument -p:PackageId=<PackageId> with your dotnet build task, like:
dotnet build -c Release -p:PackageId=<PackageId>
If you have another dotnet pack task to package your package, #Martin`s answer is correct.
Note2:
When we use the option -p:PackageId to change the package ID, but the AssemblyName is not changed. So the Package ID of the generated package is not consistent with its AssemblyName. We need to pay more attention when we use this nuget package. Or we could also change the AssemblyName to make it match the package id by the option -p:AssemblyName=<AssemblyName>
Hope this helps.
Did you try calling?:
dotnet pack -c Release -p:PackageId=The.Other.Packge.id
Or the equivalent in the .NET Core CLI task
You could modify the XML of the csproj after clone and before build using the File Transform task:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/file-transform?view=azure-devops
I know Since the release of msbuild 15 (vs 2017) that NuGet is now fully integrated into MSBuild.
I have a nuspec file with defining variables of package properties like:
<metadata>
<id>$id$</id>
<version>$version$</version>
<authors>$authors$</authors>
...
</metadata>
The nuspec file is located in the same folder of the project.
When using nuget tool to create the package , it works fine.
nuget pack
When using msbuild v15, it raise an exception.
run the command:
msbuild -version
Microsoft (R) Build Engine version 15.8.168+ga8fba1ebd7 for .NET Framework
15.8.168.64424
msbuild /t:pack /p:configuration=release /p:NuspecFile=mylib.nuspec
raise exception:
C:\Program Files\dotnet\sdk\2.1.402\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(199,5): error : Value cannot be null or an empty string.
The strange is that dotnet sdk version 2.1.402 raises the exception.
I tried msbuild installed with vs2017 with its path and also it raises the same exception.
When i substitute the variables with its values, msbuild is working fine.
The question
Is this a bug in msbuild version 15.8.168.64424 or i missed something ?
In other words, Can msbuild support using the metadata variables of the package?.
As has been mentioned in the comments, you no longer need a Nuspec file as most aspects can be controlled via properties in the csproj file or additional metadata on items (e.g. if you need additional content).
If you do need a nuspec file for some reason, you need to provide the variables for substitution yourself. You can do this in a target inside the csproj file like this:
<Target Name="SetNuspecProperties" BeforeTargets="GenerateNuspec">
<PropertyGroup>
<NuspecProperties>$(NuspecProperties);id=$(AssemblyName)</NuspecProperties>
<NuspecProperties>$(NuspecProperties);config=$(Configuration)</NuspecProperties>
<NuspecProperties>$(NuspecProperties);version=$(PackageVersion)</NuspecProperties>
<NuspecProperties>$(NuspecProperties);description=$(Description)</NuspecProperties>
<NuspecProperties>$(NuspecProperties);authors=$(Authors)</NuspecProperties>
</PropertyGroup>
</Target>
We have been using a Bamboo build server for a while now and we have GitVersion installed so it can be selected as a task in the Build plan. We typically use the /UpdateAssembleInfo argument when we run the task. For .NET Framework projects, this would update the assemblyinfo file in the source with the bamboo versioning settings so the .NET assemblies had the same version info as our Bamboo builds and subsequent Bamboo deployment, allowing us to know the version of the deployed project in the field by examining the assembly file properties. This was all working quite well.
However, we are now building and deploying .NET Core 2.0 solutions and are finding that GitVersion /UpdateAssemblyInfo is not working.
I searched for a fix for .NET Core but was only able to find solutions that involved using the project.json file, which is no longer used with .NET Core 2.0 ( it changed to the *.csproj file).
I looked at http://gitversion.readthedocs.io/en/latest/usage/command-line/ and I tried running
gitversion.exe /UpdateAssemblyInfo MyProjectName.AssemblyInfo.cs /EnsureAssemblyInfo
where MyProjectName represents the actual project name suffix for the assemblyinfo.cs file in the .NET Core 2.0 ..\\obj\release\netcoreapp2.0 folder. But it did not update that file.
I have to assume that there has to be a solution for using GitVersion with Bamboo and.NET Core 2.0 but I am having a hard time finding one.
Any ideas?
The latest version of GitVersion provides /updateprojectfiles switch to update version info in the Sdk-style .csproj/.vbproj/.fsproj recursively.
From GitVersion/Usage/CommandLine/Arguments:
/updateprojectfiles
Will recursively search for all project files
(.csproj/.vbproj/.fsproj) files in the git repo and update them
Note: This is only compatible with the newer Sdk projects
It produces the needed attributes even if they are not present in the project files, resulting in following properties:
<Project>
<PropertyGroup>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
<InformationalVersion>1.0.0-versionNumber.N+Branch.branchName.Sha.commitId</InformationalVersion>
<Version>1.0.0-versionNumberNNNN</Version>
</PropertyGroup>
As a workaround, you may consider specifying the assembly info as project properties in .csproj
<PropertyGroup>
<Version>1.2.3.4</Version>
<AssemblyVersion>2.0.0.0</AssemblyVersion>
...
</PropertyGroup>
and then setting values during dotnet build. In addition to its options, the dotnet build command accepts MSBuild options like /property
/property:name=value
/p:name=value
Set or override the specified project-level properties, where name is the property name and value is the property value. Specify each property separately, or use a semicolon or comma to separate multiple properties.
So your build command will be something like
dotnet build /p:Version=1.2.3.4;AssemblyVersion=1.2.3.4
I am having a problem with nuget (version 4.3.0.4406) and msbuild (version 15.3.409.57025). I am using VS2017 to create class library. Using the pack capability of VS2017 i can successfully create a nuget package (that i can install in another solution). Now i want to add an install.ps1 script to the package in the tools folder that runs when the nuget is installed.
In the csproj file i am specifying multiple target frameworks:
<TargetFrameworks>net45;net452</TargetFrameworks>
I cannot figure out how to do this. I've created a nuspec file using the nuget -spec command which generates a simple nuspec file. When i use the msbuild command with the /t:pack and /p:Nuspecfile=path.to.nuspec I get the following errors:
NuGet.Build.Tasks.Pack.targets(141,5): error : Value cannot be null or an empty string.
I have nuspec files from other projects (from VS2015 solutions) that work without problem, and the structure of the one i am using now is basically the same. Can anyone let me know whether i am trying something that cannot be done?
You can pack any item by updating its metadata in the csproj file:
<ItemGroup>
<None Update="install.ps1" CopyToOutputDirectory="PreserveNewest" Pack="true" PackagePath="\tools" />
</ItemGroup>
Note that the ps1 file is only run for projects using packages.config to reference the NuGet package and you should investigate alternative ways to accomplish what you are trying to do with the script as PackageReference is now more likely to be used instead.