如何在osx

时间:2017-10-19 12:26:50

标签: macos .net-core .net-standard .net-standard-2.0

我正在使用Visual Studio for Mac,我的应用程序已编写,它可以满足我的需求。用户的目标平台是OSX。它依赖于2个具有自己依赖关系的Nuget包,特别是:

  • NetMQ
  • Microsoft.Extensions.Configuration.CommandLine

我运行以下命令到build应用程序:

dotnet build -c Release -r osx.10.11-x64

输出告诉我它成功了,并告诉我放置文件的位置。

包含在该文件夹中的是以下文件,我认为这个文件夹是我分发给我的用户的,但这会导致错误,因此这个问题:

MyApp <---- executable
MyApp.deps.json
MyApp.dll
MyApp.pdb
MyApp.runtimeconfig.dev.json
MyApp.runtimeconfig.json
libhostfxr.dylib
libhostpolicy.dylib

所以我的用户收到了这个,他们安装了dotnet运行时。当他们去运行可执行文件时(这里MyApp又称./MyApp),他们会收到以下错误:

An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found:
package: 'AsyncIO', version: '0.1.26'
path: 'lib/netstandard1.3/AsyncIO.dll'

现在,AsyncIONetMQ的依赖关系,因此它就是来自的地方。但是,我可以从我的文件系统的任何位置./MyApp,它的工作原理。因此,我认为我的系统上安装的Nuget软件包作为开发系统仍然可以访问,而新用户的系统则不然。我还没有找到任何与Mac发行有关的文档。我现在唯一能想到的就是分发项目文件,并指示用户运行:

dotnet run -p MyApp.csproj

如果我理解正确,将安装nuget软件包。

我也可以让用户使用:

dotnet MyApp.dll

我在google搜索中看到了这种形式。这引起了他们的质疑,但是为什么会生成可执行文件。乞丐不能选择,如果这样做dotnet <dll>我很高兴,我只需要让它运行。

我必须在这里找到一些东西,否则netcore2.0应用程序的这个细节,分布只是被忽略了?

在挖掘更多内容时,这似乎也是一个有用的命令:

dotnet publish -c Release --framework netcoreapp2.0 --runtime osx.10.11-x64

这也添加了各种DLL和所有依赖DLL。像publish这样的词语让我觉得这就是他们需要的方式。

这两个链接是我主要获取信息的地方:

https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli https://docs.microsoft.com/en-us/dotnet/core/tools/project-json-to-csproj

3 个答案:

答案 0 :(得分:14)

您对buildpublish之间的区别有正确的直觉。

dotnet build将为本地开发构建应用程序。一个方面是构建将假设所有依赖项都可通过本地nuget缓存获得。

dotnet publish将构建应用程序以部署到其他计算机。这明确地处理了依赖关系。

有两种发布模式:自包含部署和依赖于框架的部署。

依赖于框架的部署依赖于系统中已存在的框架。如果以此模式发布应用程序,则只包括应用程序及其依赖项。

要在FDD中发布,请使用:

dotnet publish -c Release --framework netcoreapp2.0
相反,

自包含部署将包括整个.NET Core运行时您的应用程序及其依赖项。

要发布SCD,请使用:

dotnet publish -c Release --framework netcoreapp2.0 --runtime osx-x64

(顺便说一下,请使用更通用的osx-x64而不是非常具体的osx.10.11-x64

你看到两种出版方式的区别吗?它只是运行时ID的存在/不存在。在您的示例中,当您使用--runtime标志时,您要求将您的应用程序发布为SCD,最终包括所有.NET Core运行时。只要把它拿出来就应该得到你期望的结果。

将应用程序发布为FDD时,应在源代码中看到名为bin/Release/netcoreapp2.0/publish的目录。使用 目录(和 bin/Release/netcoreapp2.0/)作为发布存档。您的用户应该只运行dotnet ./path/to/publish/MyApp.dll

请查看https://docs.microsoft.com/en-us/dotnet/core/deploying/了解详情。

答案 1 :(得分:1)

跟进@omajid's answer

如果您想将您的控制台应用程序打包到一个漂亮整洁的包中,您只需“单击”它,它就会打开一个终端来启动您的应用程序……这是一个示例应用程序(带有树形图标):

您首先需要这样的文件夹/文件结构(开始 mkdir!):

enter image description here

然后在info.plist中,直接粘贴

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundleDevelopmentRegion</key>
    <string>English</string>
    <key>CFBundleExecutable</key>
    <string>launcher</string>
    <key>CFBundleIconFile</key>
    <string>trees.icns</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundlePackageType</key>
    <string>APPL</string>
    <key>CFBundleShortVersionString</key>
    <string>2.2</string>
    <key>CFBundleSignature</key>
    <string>xmmd</string>
    <key>CFBundleVersion</key>
    <string>2.2</string>
    <key>NSAppleScriptEnabled</key>
    <string>NO</string>
</dict>
</plist>

从某个 .icns site off the internet 获取您的“trees.icns”。

然后将 dotnet publish -c Release --framework netcoreapp3.1 --runtime osx-x64 命令中的所有内容复制到 osx-x64 文件夹中(这里将有大量 .dll 文件。我有 ~197 个)

enter image description here

最后在 launcher 中添加以下脚本:

#!/bin/sh

# Set the working directory
DIR=$(cd "$(dirname "$0")"; pwd)

# Run the application
echo "running from $DIR/osx-x64"

open -a Terminal $DIR/osx-x64/dotnetconsole

然后瞧...进入您的查找器并单击“MyApp”应用程序 enter image description here

参考:packaging jar tutorial

答案 2 :(得分:0)

仍然可以追溯到他最初的观察,即我所看到的,可执行文件“ MyApp”不是真正独立的二进制文件。如果将该二进制文件移动到其他目录,它将抱怨找不到MyApp.dll。

具体来说,我使用的命令是:

dotnet new console
dotnet publish -c Release --runtime osx.10.12-x64 --self-contained true

我遇到了同样的问题,我的“ MyApp”实际上不是一个自包含的应用程序。实际上,我发现'MyApp'至少需要在其存在的目录中包含以下文件:

MyStatic     ----> my 'exe'                   
MyStatic.dll                    
libhostpolicy.dylib
MyStatic.deps.json              
MyStatic.runtimeconfig.dev.json

任何独立的二进制文件都不需要所有这些垃圾来独立运行。