我有一个dotnet核心类库,我已成功使用dotnet cli" dotnet build --configuration Release"来构建。这很重要,因为我也在Jenkins的Linux服务器上构建这个项目。
最近,我需要进入并对项目进行一些修改。使用" dotnet build --configuration Release"再次构建它时,它已构建,但我的更改和添加都没有出现。请注意,当使用" dotnet build --configuration Release"时,它在Linux中的Jenkins环境和我的Windows 10命令提示符之间表现一致(成功和失败)。
如果我使用Visual Studio 2015构建(我假设使用MSBuild),那么在构建类库之后,所有更改都会出现,并且所有更改都适用于世界。
我认为我的project.json有问题吗?
{
"version": "1.0.0.*",
"dependencies": {
"NETStandard.Library": "1.6.0",
"Dapper": "1.50.2",
"Dapper.Mapper": "1.50.1"
},
"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
]
}
}
}
答案 0 :(得分:0)
您可能已经做到了,但是您是否在linux中重新启动了服务?
答案 1 :(得分:0)
因此事实证明,这个问题的根本原因只是我错误地构建了我的解决方案并且没有引用该项目的gobal.json文件。我不完全确定修复它,或者为什么修复它,但我的类库解决方案需要以下内容: SolutionItems文件夹中的global.json src文件夹 - 项目在src文件夹中 - src文件夹中的单元测试
接下来,linux服务器的问题是它的nuget push命令无法识别dotnet核心版本字符串。这在nuget cli版本3.5.0中已得到解决,但Linux尚不支持该版本。作为一个临时备份,我在运行Jenkins和nuget cli版本3.5.0的基于Windows的机器上创建了相同的工作,它完美无缺。
当下一个版本的dotnet核心问世,并且有一个dotnet nuget push命令时,我确信我可以重新访问Linux服务器。
然后我在Jenkins运行的命令是 dotnet恢复 dotnet pack - 配置版本--versionsuffux%BUILD_NUMBER% nuget push PackageName ApiKey -Source http://NugetSource
答案 2 :(得分:0)
如果依赖项或库已更改,则旧文件会影响打包操作。
obj
和bin
文件夹。dotnet restore
dotnet build --configuration Release