Open kant2002 opened 6 years ago
Hi @kant2002. Thanks for reporting this to us. I don't think we've considered this scenario fully. Including @wli3 to the discussion.
As a possible workaround (one I haven't tried), would it be possible to make setting PackAsTool
conditional on '$(TargetFramework)' == 'netcoreapp2.1'
?
Yes, indeed this working. Thanks, that's at least allow me move forward, and don't play with shared projects or additional dependencies too much.
My mistake. It is actually pack right now without errors
tools\netstandard2.1\any
contains all dependenciesDotnetToolSettings.xml
present and contains valid information (at first sight)What is not here is
<packageTypes>
<packageType name="DotnetTool" />
</packageTypes>
part is missing from NUSPEC file
For additional information, if this is needed, I specify condition like this.
<PropertyGroup Condition="'$(TargetFramework)' == 'netcoreapp2.1'">
<PackAsTool>true</PackAsTool>
</PropertyGroup>
This is expected and deliberate. As of today, global tools only support netcoreapp2.1
@wli3 Please reopen, I understand why I have such error, but it does not cover my use-case, and I think it is justifiable to want create both regular EXE file and dotnet global tool. Not everybody jump on the .NET Core bandwagon, and distribute small EXE with dependency as ZIP archive is still viable option. Why I have to duplicate code in two different projects, then all what I want is create both regular EXE and global tool from same project. I understand that netcoreapp2.0 or net462 would not work as global tools. Maybe technically not the same, but regular console application and global tool is same for me, but global tool is just different distribution mechanism.
Maybe this should be documentation issue. If such, you could point me to the appropriate location, so I would ask there. And if that documentation issue, I could contribute to it as well, as well I want to contribute here.
@KathleenDollard
@kant2002 thank you. I understand your scenario. Let me change the title to global tools full framework support. And mark it as a feature requires.
Ask for documentation. We have several documentation in process for global tools for 2.1.300 release.
I faced the same problem and I did the following workaround solution:
To avoid creation of shared project:
(net45;netappcore2.1)
ASIS, no PackAsToolCreate new project for the global tool (MyGlobalTool.csproj) : netappcore2.1
with PackAsTool = true
Add reference to MyConsole
project application
in netcoreapp MyGlobalTool project, create a class with Main method that call MyConsole.Main()
class Program { static void Main(string[] args) { MyConsole.Program.Main(args); //Main method in MyConsole application. } }
The advantage of this solution:
Found a way to put it all in one csproj:
<PropertyGroup>
<TargetFrameworks>net40;netcoreapp2.1</TargetFrameworks>
<PackAsTool Condition="$(TargetFramework) != 'net40'">true</PackAsTool>
<SuppressDependenciesWhenPacking>true</SuppressDependenciesWhenPacking>
</PropertyGroup>
The resulting nupkg:
<packageType name="DotnetTool" />
.tools\netcoreapp2.1\any
directory with files in it.lib
directory.<group targetFramework=".NETFramework4.0" />
.dotnet tool install
and run.<frameworkAssemblies>
<frameworkAssembly assemblyName="WindowsBase" targetFramework=".NETFramework4.0" />
</frameworkAssemblies>
My idea is to have both global tool, and regular application, so non developers could be targeted with app running full framework
Steps to reproduce
dotnet pack
Expected behavior
Generate pack only for
netcoreapp2.1
or provide ability to select which TFM targetActual behavior
Environment data
dotnet --info
output:Пакет SDK для .NET Core (отражающий любой global.json): Version: 2.1.300-rc1-008673 Commit: f5e3ddbe73
Host (useful for support): Version: 2.1.0-rc1 Commit: eb9bc92051