mirrors/dotnet-installer
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
dotnet-installer/TestAssets/TestProjects/TestMicrosoftCSharpReferenceMissingFramework/project.json

33 lines
630 B
JSON
Raw Normal View History

Fix duplicate dependency issue (#2597) * Fix duplicate dependency issue If a package has the same name as a framework assembly in the dependency graph, we usually replace it with the framework assembly if the package provides no assets. If the framework assembly wasn't resolved, it would skip this logic and end up adding dupes to the list, which blows up later on. This is a tactical fix to solve the issue, we need to do some more thinking to determine how we want to resolve conflicts between framework assemblies, packages and dlls with the same name.
2016-04-21 16:05:55 +00:00
{
"version": "1.0.0",
"dependencies": {},
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50",
"dependencies": {
Upgrade the RC2 branding to RC3. The following packages are changing: Microsoft.NetCore.App: 1.0.0-rc2-3002702 -> 1.0.0-rc3-002702 Microsoft.NETCore.DotNetHost: 1.0.1-rc2-002702-00 -> 1.0.1-rc3-002702-00 Microsoft.NETCore.DotNetHostPolicy: 1.0.1-rc2-002702-00 -> 1.0.1-rc3-002702-00 Microsoft.NETCore.DotNetHostResolver: 1.0.1-rc2-002702-00 -> 1.0.1-rc3-002702-00 Also publishing the *deb file to teh debian repo feed is disabled - https://github.com/dotnet/cli/issues/2973
2016-05-10 20:22:58 +00:00
"Microsoft.NETCore.App": "1.0.0-rc3-*"
Fix duplicate dependency issue (#2597) * Fix duplicate dependency issue If a package has the same name as a framework assembly in the dependency graph, we usually replace it with the framework assembly if the package provides no assets. If the framework assembly wasn't resolved, it would skip this logic and end up adding dupes to the list, which blows up later on. This is a tactical fix to solve the issue, we need to do some more thinking to determine how we want to resolve conflicts between framework assemblies, packages and dlls with the same name.
2016-04-21 16:05:55 +00:00
}
},
Fixed netcore50 package based frameworks (#2630)
2016-04-22 04:47:20 +00:00
"netcore50": {
"dependencies": {
Updating core packages to rc3-24123-01
2016-05-24 00:04:20 +00:00
"System.Private.Uri": "4.0.1-rc3-24123-01"
Fixed netcore50 package based frameworks (#2630)
2016-04-22 04:47:20 +00:00
}
},
Fix duplicate dependency issue (#2597) * Fix duplicate dependency issue If a package has the same name as a framework assembly in the dependency graph, we usually replace it with the framework assembly if the package provides no assets. If the framework assembly wasn't resolved, it would skip this logic and end up adding dupes to the list, which blows up later on. This is a tactical fix to solve the issue, we need to do some more thinking to determine how we want to resolve conflicts between framework assemblies, packages and dlls with the same name.
2016-04-21 16:05:55 +00:00
"net99": {
"dependencies": {
Updating core packages to rc3-24123-01
2016-05-24 00:04:20 +00:00
"Microsoft.CSharp": "4.0.1-rc3-24123-01"
Fix duplicate dependency issue (#2597) * Fix duplicate dependency issue If a package has the same name as a framework assembly in the dependency graph, we usually replace it with the framework assembly if the package provides no assets. If the framework assembly wasn't resolved, it would skip this logic and end up adding dupes to the list, which blows up later on. This is a tactical fix to solve the issue, we need to do some more thinking to determine how we want to resolve conflicts between framework assemblies, packages and dlls with the same name.
2016-04-21 16:05:55 +00:00
}
}
Remove '--infer-runtimes' option for 'dotnet restore' when restoring TestAssets.
2016-05-18 02:44:18 +00:00
},
"runtimes": {
"win7-x64": {},
"win7-x86": {},
"osx.10.10-x64": {},
"osx.10.11-x64": {},
"ubuntu.14.04-x64": {},
"centos.7-x64": {},
"rhel.7.2-x64": {},
"debian.8-x64": {}
Fix duplicate dependency issue (#2597) * Fix duplicate dependency issue If a package has the same name as a framework assembly in the dependency graph, we usually replace it with the framework assembly if the package provides no assets. If the framework assembly wasn't resolved, it would skip this logic and end up adding dupes to the list, which blows up later on. This is a tactical fix to solve the issue, we need to do some more thinking to determine how we want to resolve conflicts between framework assemblies, packages and dlls with the same name.
2016-04-21 16:05:55 +00:00
}
}
Reference in a new issue Copy permalink