当前位置: 澳门新濠3559 > 编程 > 正文

目前基础类库均为.NET Framework,Visual Studio中对项

时间:2019-11-09 19:37来源:编程
微软近几年推出.NET Standard,将.NET Framework,.NETCore,Xamarin等目标平台的api进行标准化和统一化,极大地方便了类库编写人员的工作。简单的说,类库编写人员在发布库的时候,只需要基于

微软近几年推出.NET Standard,将.NET Framework,.NET Core,Xamarin等目标平台的api进行标准化和统一化,极大地方便了类库编写人员的工作。简单的说,类库编写人员在发布库的时候,只需要基于.NET Standard进行发布,那么编写的程序可以在各个目标平台上都能到运行。

公司的项目一直采用.NET框架来开发Web项目。目前基础类库均为.NET Framework 4.6.2版本。Caching, Logging,DependencyInjection,Configuration等基础设施相关的依赖库一直和官方保持同步,目前是1.1版本。.NET Core越来越趋于稳定,新的开发工具也在三月份发布。因此,计划将.NET Framework移植至.NET Core/Strandard。目的是使基于.NET开发的Web应用可以跨平台运行。

最近在看ASP.NET Core MVC的教材,几乎每章开始都要重复从Empty project开始创建一个ASP.NET Core的项目,然后手动修改project.json,增加经典三目录(Models,Controllers,Views)之类的,然后接着基于这个基本项目进行介绍某个特定的功能。

以下基于.NET Framework4.6及.NET Core2.0

.NET Standard是一种标准,只要符合这个标准的平台都可以运行基于此标准api构建的程序。

按应用场景将公司的项目分为基础类库,基础服务和应用项目。基础类库以包的形式提供各类基础功能。基础服务通过Wcf项目搭建或者通过Web API项目搭建。应用项目则是Web Mvc项目为主。基础类库和基础服务是以一个一个解决方案的形式存在。每个解决方案的结构,包含一个或者多个类库项目,一个或多个控制台项目,它们分别用于功能实现、单元测试、功能演示。如果全部要移植,那么优先级应该是基础类库 -> 基础服务 -> 应用项目。此次移植的对象是基础类库。

这种示例代码每次都重复创建很没有技术含量,通常都是复制粘贴,所以考虑把这部分示例代码做成一个自动化的。之前有看到有ASP.NET Identity的示例的Nuget程序包,就是安装之后,自动创建了相关的类文件,同时也修改了web.config,最终效果是安装了package之后,直接能起来。

用于配置项目信息,如:

感觉挺好用的,但是实际上用起来就有一些坑了。比如说这个常见的FileNotFoundException,当有这个情况的时候,经常出现:

基础类库最终会以包的形式通过NuGet发布出去,目前只面向.NET Framework框架。移植的目标之一,是让包也能被面向.NET Core、.NET Standard框架的项目引用。结合官方资料,我选择了直接迁移的方案。即直接将项目文件转换为新的基于.NET Core的项目文件。下面详细说明移植的细节。

遵循这个想法,也打算创建一个ASP.NET Core MVC的基本示例Nuget包。于是从新复习了一个创建Nuget包的文档,发现情况不是那么直接,用之前基于非.NET Core的程序的创建包的方式,行不通。

  • 程序集名称、类型
  • Framework版本
  • 项目所包含的文件信息,如:cs、html、js、config、xml等
  • 项目所引用的程序集信息,包含本地dll与Nuget包
  • 其它信息

主程序的目标平台是某个具体平台(不是.NET Standard,比如说是.NET Framework 4.0),随后为了引入新的特性,升级了Framework为4.6.1,它并且引用了一个.NET Standard类库,恰好,这个类库还引用了其他的package。(即传递引用A->B->C的形式,其中A是.NET Framework程序,B是nuget包,C是B引用的nuget包。)在此情况下,如果F5启动程序,就会报FileNotFoundException。

  1. 新建基于.NET Core的项目。

查看了Nuget提供的文档说明(),也没找到很直接的说明如何创建.NET Core程序包的介绍文档,反而看到有介绍创建.NET Standard程序包的文档。这是什么情况,按道理不可能,可能方向不对?直接bing了一下,也没有找到stackflow上的最佳答案,其实也没深入去找,我是觉得自己走错了方向。

Visual Studio中对项目所做的配置,均可在该文件中体现出来。同样,Visual Studio也是根据该文件中的内容来加载项目的。抛开Visual Studio的其它功能,可以将其看作是.csproj文件的图形管理工具。

测试条件
Visual Studio 2015 Community
测试用包:UnifiedConfig v1.1.6

首先重命名现有项目文件*.csproj为*.Net46.csproj。然后使用VS2017新建一个新的基于.NET Core的项目,项目类型可以是“类库(.Net Core)”或者“类库(.Net Standard)”。注意,VS2017会提示存在同名目录,所以创建时可以输入一个不同的名称,然后手工调整回来。

于是把介绍创建.NET Standard的文档()看了一遍,看到前面的介绍终于明白了,原来是换了个壳,没有之前那么直接了,必须通过创建.NET Standard包的方式实现对.NET Core程序的支持。

使用Visual Studio创建Web项目(MVC或Web Api)时,会在根目录生成Web.config文件。创建控制台程序则会生成App.config文件。以Web.config为例,该文件用于配置Web项目运行时所需的信息,如:

提示未找到System.IO.FileSystem。乍看感觉是一个简单的引用错误,但unifiedconfig包里面已经正常引用了这个项目,按道理vs能够正常帮我们处理引用问题。到文件输出路径中查看,发现对应的包没有正确复制过来。手动从package文件夹中复制过来,问题解决。

图片 1

为什么是.NET Standard?.NET Standard定义了支持所有.NET平台的BCL程序集API,理论上说.NET Standard支持下的程序集可以在多个不同的.NET平台运行,比如.NET Framework,.NET Core, Mono等等。而对于不同的.NET平台,对.NET Standard的版本支持也不同,完成的支持列表可参考的说明,下图是引用自官网的一个版本支持图

  • Framework版本信息

    <system.web> <compilation debug="true" targetFramework="4.6.2"/> <httpRuntime targetFramework="4.6.2"/></system.web>
    
  • 编译器信息

    <system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701"/> </compilers></system.codedom>
    
  • 所引用的程序集信息

    注意,这里所引用的是项目在运行时所需的程序集,而.csproj中描述的程序集是项目中添加的引用,二者有区别:项目中添加的引用在运行时未必会用到。

    <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/> <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35"/> <bindingRedirect oldVersion="0.0.0.0-5.2.4.0" newVersion="5.2.4.0"/> </dependentAssembly> </assemblyBinding></runtime>
    

    若项目启动后报错:未能加载文件或程序集“XXXXXX”或它的某一个依赖项,找到的程序集清单定义与程序集引用不匹配,则应当检查下项目所引用的dll文件与Web.config中配置的dll文件信息是否一致。

    点击此处,可查看关于配置文件中bindingRedirect的解释。

原因出在这个跨平台上。由于存在引用传递,B不能确定需要复制哪个目标平台的package到A的输出路径。当程序是从旧的Framework升级而来的时候,旧版的项目文件不能很好地处理.NET Standard的这个问题。但我们手动一个一个复制也不是办法,以下给出解决方案。

 

图片 2

.NET Core官方项目模板中默认不生成App.config或Web.config。注意,.NET Core项目(Console、ASP.NET Core)本质上是控制台程序,若要使用XML格式作为配置文件,建议使用App.config。

解决方案:

  1. 编辑项目文件,使之支持面向多个目标框架。

参考需要支持的.NET平台的版本,可以看到平台支持的最高版本的.NET Standard的版本号,同时也说明支持之前版本的.NET Standard。

Windows系统中,可通过%AppData%NuGetNuGet.config对Nuget进行配置,文件结构如下:

  1. 最直接的方案,修改主项目的.csproj文件,将<RestoreProjectStyle>PackageReference</RestoreProjectStyle>添加到第一个PropertyGroup
  2. 如果还不行,加上<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    或者

通过VS2017 RC新建的项目,“类库(.Net Core)”或者“类库(.Net Standard)”,默认只有一个目标框架。我们可以编辑项目文件,使之支持面向多个目标框架。如支持目标框架为.NET Standard 1.4、.Net Core App 1.0和.NET Framework 4.5,则这样来修改。

说的比较拗口,比如我这里需要支持.NET Core程序,而且是.NET Core 1.0版本,那么这个版本支持的最高.NET Standard版本是1.6,同时也兼容1.6之前的版本。

<?xml version="1.0" encoding="utf-8"?><configuration> <config> <add key="globalPackagesFolder" value="D:DevNugetPackages" /> </config> <packageSources> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" /> </packageSources> <packageRestore> <add key="enabled" value="True" /> <add key="automatic" value="True" /> </packageRestore> <bindingRedirects> <add key="skip" value="False" /> </bindingRedirects> <packageManagement> <add key="format" value="0" /> <add key="disabled" value="False" /> </packageManagement> <disabledPackageSources> </disabledPackageSources></configuration>
  • 在工具->nuget包管理器->程序包管理->默认包管理格式,从Packages.config改成PackageReference。
<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
      <TargetFrameworks>netstandard1.4;netcoreapp1.0;net45</TargetFrameworks>
    </PropertyGroup>
</Project>

好了前面介绍了一下背景知识,那么了解完之后我们就很清楚如果要创建支持.NET Core的Nuget包,那么我们需要创建一个支持.NET Standard的Nuget包,并且设置支持的版本即可。

packages.config是项目中用于管理Nuget包的引用的文件,对于Nuget包的操作(添加、删除与版本变更)都会反映到该文件中。也可以直接操作该文件来修改项目中的Nuget包,但不建议这么做。文件结构如下:

后记

我记得在visual studio 2017早期版本还存在这个bug,升级之后visual studio 2017 15.6.4这个版本测试新建项目,已经没有这个问题。并且默认生成的基于4.5.2以上Framework的.csproj文件已经添加<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>这个配置。但是当老版本的项目引用.NET Standard类库的时候,还是经常会出现这个问题,这时候,就需要我们手动添加配置项目了。

注意,官方文档中提供了.NET支持的目标框架列表,你可以查询更多其他的目标框架。如果要兼容较低版本的框架,则目标框架版本不宜设置过高。如“net45”可用于.NET Framework 4.5 ~ 4.6.2等版本。如“net46”则只能用于.NET Framework 4.6 ~ 4.6.2等版本。

结合Nuget官方的文档,我们一步步来创建并发布一个Demo版的支持.NET Core 1.0版本的Nuget包。

<?xml version="1.0" encoding="utf-8"?><packages> <package version="6.2.0" targetFramework="net462" /> <package version="5.2.4" targetFramework="net462" /></packages>
  1. 修改应用程序代码相关API,使之支持多个目标框架。

1 用Visual studio 2015新建一个Class Library Portable项目

默认在sln文件所在目录下会生成packages文件夹用于存放项目引用的Nuget包:

a. 因目标框架提供的API不相同。故必要时可添加条件编译符号以便支持不同的运行时版本。

图片 3

图片 4packages_floder

以下是常见的条件编译符号列表。

项目名称自定义,通常用于最终Nuget包的名称

我们通过Nuget命令行或者Visual Studio中的图形界面来管理Nuget包,当Nuget包发生变更时,packages.config与.csproj文件内容及packages文件夹都会发生相应的变化。如,我们添加对Dapper的引用后

.NET Framework 2.0 --> NET20
.NET Framework 3.5 --> NET35
.NET Framework 4.0 --> NET40
.NET Framework 4.5 --> NET45
.NET Framework 4.5.1 --> NET451
.NET Framework 4.5.2 --> NET452
.NET Framework 4.6 --> NET46
.NET Framework 4.6.1 --> NET461
.NET Framework 4.6.2 --> NET462
.NET Standard 1.0 --> NETSTANDARD1_0
.NET Standard 1.1 --> NETSTANDARD1_1
.NET Standard 1.2 --> NETSTANDARD1_2
.NET Standard 1.3 --> NETSTANDARD1_3
.NET Standard 1.4 --> NETSTANDARD1_4
.NET Standard 1.5 --> NETSTANDARD1_5
.NET Standard 1.6 --> NETSTANDARD1_6

2 点击确定之后弹出选择需要的Targets,也就是支持的.NET平台

packages.config:

 关于条件编译符号的应用,如以下代码:

图片 5

<?xml version="1.0" encoding="utf-8"?><packages> <package version="1.50.0" targetFramework="net461" /></packages>
using System;
using System.IO;
namespace Baza.NetStandardTester
{
    public class PathHelper
    {
        public string BaseDirectory { get; set; }
        public PathHelper()
        {
#if NET45
            BaseDirectory = AppDomain.CurrentDomain.BaseDirectory;
#endif
        }
        public string GetRootedPath(string path)
        {
            string rootedPath = path ?? string.Empty;
            if (!Path.IsPathRooted(rootedPath))
            {
                if (string.IsNullOrEmpty(BaseDirectory))
                    throw new ArgumentNullException("请先设置BaseDirectory属性");
                rootedPath = Path.Combine(BaseDirectory, rootedPath);
            }
            string directory = Path.GetDirectoryName(rootedPath);
            if (!string.IsNullOrEmpty(directory) && !Directory.Exists(directory))
            {
                Directory.CreateDirectory(directory);
            }
            return rootedPath;
        }
    }
}

这里选择支持.NET Framework和ASP.NET Core

.csproj:

代码说明,PathHelper提供GetRootedPath方法用于根据相对路径计算出绝对路径。当运行时为.NET Core时,BaseDirectory属性需要手动设置。当运行时为.NET Framework 4.5时,由构造器对BaseDirectory属性进行赋值。注意System.AppDomain.CurrentDomain.BaseDirectory用于获取托管程序执行路径,类AppDomain只存在于.NET Framework中。

3.点击OK之后,项目创建完成,然后右键点击解决方案,打开属性窗口

<?xml version="1.0" encoding="utf-8"?><Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <Reference Include="Dapper, Version=1.50.0.0, Culture=neutral, processorArchitecture=MSIL"> <HintPath>..packagesDapper.1.50.0libnet451Dapper.dll</HintPath> </Reference> </ItemGroup></Project>

b. .NET Standard是个基于包的框架。当你需要某个API时,如IDataReader,你需要安装System.Data.Common包。如果是使用.NET Framework,则在命名空间System.Data下可以找到IDataReader而无需按照包。借助工具,你可以快速定位某个API在哪个包中。

图片 6

若直接修改packages.config中的内容,如,直接删除packages.config中对某个包的引用,.csproj文件中依然保留了对该包的引用,及packages文件夹中也会保留该包。这样很有可能导致项目引用的混乱,所以,不建议直接操作packages.config文件。

c. 基于.NET Core的项目,包版本号和其他元数据,都存储在*.csproj中,不会使用AssemblyInfo.cs文件,即移植时,这个文件可以删除。但是.NET Framework项目还是会继续使用该文件。

选择点击”Target.NET Platform Standard”,之后会有一个Confirm,当然是选择“Yes”

.NET Core项目中不在使用packages.config文件文件管理Nuget包,对于Nuget包的引用直接反映到.csproj文件中:

  1. 同一解决方案,类库间的引用策略。

图片 7

<Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>netcoreapp2.1</TargetFramework> </PropertyGroup> <ItemGroup> <Folder Include="wwwroot"/> </ItemGroup> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.App"/> <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.1.2" PrivateAssets="All"/> </ItemGroup></Project>

在引用类库时,要注意目标框架的兼容问题。如,“类库(.Net Standard)”项目,能够被.NET Core App、.NET Framework和其他.NET Standard项目引用。这个是因为.NET Core App和.NET Framework都支持相应版本的.NET标准库。下表显示了支持 .NET 标准库的整套 .NET 运行时。

然后属性窗口的Target变成了一个下拉选项,这里我们选择.NET Standard1.4版本即可(根据版本支持图,.NET Core 1.0可以支持这个版本)

sln文件所在目录下也没有packages文件夹。Windows系统下.NET Core中Nuget包位于%UserProfile%.nugetpackages

平台名称 Alias                
.NET Standard netstandard 1.0 1.1 1.2 1.3 1.4 1.5 1.6 2.0
.NET 核心 netcoreapp 1.0 vNext
.NET Framework net 4.5 4.5.1 4.6 4.6.1 4.6.2 vNext 4.6.1
Mono/Xamarin 平台   vNext
通用 Windows 平台 uap 10.0 vNext
Windows win 8.0 8.1          
Windows Phone wpa 8.1          
Windows Phone Silverlight wp 8.0              

图片 8

可以使用.NET Core提供的CLI中的命令来获取nuget包的位置:

注意,如果项目是面向多目标框架的,那么引用类库时,被引用类库也要支持面向多目标框架。

之后再次Confirm,Yes

dotnet nuget locals all -linfo : http-cache: C:UsersxfhAppDataLocalNuGetv3-cacheinfo : global-packages: C:Usersxfh.nugetpackagesinfo : temp: C:UsersxfhAppDataLocalTempNuGetScratchinfo : plugins-cache: C:UsersxfhAppDataLocalNuGetplugins-cache
  1. 单元测试

图片 9

也可以使用Nuget自身命令来获取nuget包位置:

如果是使用.NET Framework类库项目来存放单元测试代码,那么可能会遇到一点问题。在VS2017 RC中,测试资源管理器无法识别出这些测试单元。通过新建“单元测试项目(.NET Framework)”,将生成的同名*.csproj覆盖原来的项目文件,测试管理器即可识别出来。

3 设置Build,选择Release,并勾选中XML documentation file,后面需要用到

nuget locals all -linfo : http-cache: C:UsersxfhAppDataLocalNuGetv3-cacheinfo : global-packages: C:Usersxfh.nugetpackagesinfo : temp: C:UsersxfhAppDataLocalTempNuGetScratch

图片 10

图片 11

以上,是自己的一些总结,与大家分享。

  1. MSBuild自动编译新的解决方案

4 到此项目的属性设置完成,然后把默认生成的Class1改一下,好歹改成一些有意义的东西,我改成如下内容。

Assembly Binding redirect: How and Why?

Windows下,按Release配置对整个解决方案编译。

public class Demo
{
    public void Run()
    {
        Console.WriteLine($"You're using my demo package at {DateTime.Now.ToString(CultureInfo.InvariantCulture)}");
    }
}
"c:Program Files (x86)Microsoft Visual Studio2017CommunityMSBuild15.0BinMSBuild.exe" XXX.sln /p:Configuration=Release;Platform="Any CPU"

5 项目代码已经足够了,接下来使用Nuget命令行工具,Nuget命令行工具用的是3.5版本,官方有得下载,这里把Nuget.exe文件放到了项目根目录下。

会在相关类库根目录下binRelease目录中,生成net46和netstandard1.6两个目录。

图片 12

  1. 使用dotnet-nuget-push发布包

6 然后CMD到项目所在的目录,运行nuget spec,创建一个spec文件,这个文件干嘛的不多说了,官方文档有详细说明

使用vs2017打包时,只需右击要打包的项目,选择“打包”,即可在.binDebug或.binRelease下生成XXX.0[.0].0.nupkg文件,然后将这个文件.nupkg上传至nuget.org中。通过调用dotnet-nuget-push可以自动化这个发布过程,因此这种方式会更加方便。

nuget spec

dotnet nuget push XXX.0[.0].0.nupkg -k 4003d786-0000-4004-bfdf-c4f3e8ef9b3a -s http://customsource/

然后得到一个Shenba.DemoPackage.Core.nuspec文件

k:服务器的 API 密钥 s:服务器 URL,如发布到nuget.org,则可以这样写。

7 用文本编辑器,比如notepad++编辑Shenba.DemoPackage.Core.nuspec文件

dotnet nuget push XXX.0[.0].0.nupkg -k 4003d786-0000-4004-bfdf-c4f3e8ef9b3a -s https://www.nuget.org/api/v2/package

把各个$符号的变量都改成自己的内容,比如如下内容

通常在windows下,会将dotnet-nuget-push写在批处理文件中来完成基本类库的部署工作。

<?xml version="1.0"?>
<package >
  <metadata>
    <id>Shenba.DemoPackage.Core</id>
    <version>1.0.0</version>
    <title>Shenba.DemoPackage.Core</title>
    <authors>shenba</authors>
    <owners>shenba</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>demo package for dotnet core</description>
    <releaseNotes>demo package for dotnet core released.</releaseNotes>
    <copyright>Copyright 2017</copyright>
    <tags>dotnet core demo package</tags>
  </metadata>
</package>

总结

注意id不要相同,否则后面没法提交

通过此方案迁移后,最终保留新的解决方案和项目文件,旧的解决方案和项目文件在移植的过程中被删除。之后将按照新的解决方案来跨平台开发。基本类库的移植工作就介绍到这里。源代码的移植将是个挑战。譬如部分源码所引用的API在.NET Core框架下不存在时如何处理?另外,基础服务和Web Mvc项目的移植,因为要部署到linux中。也将会遇到各种问题。

8 继续编辑nuspec文件,加入<files>节点(跟metadata一个级别),并设置内容如下

参考资源

<files>
    <file src="binReleaseShenba.DemoPackage.Core.dll" target="libnetstandard1.4Shenba.DemoPackage.Core.dll" />
    <file src="binReleaseShenba.DemoPackage.Core.xml" target="libnetstandard1.4Shenba.DemoPackage.Core.xml" />
</files>

1. 组织项目以支持 .NET Framework 和 .NET Core

9 在Release配置下,编译解决方案后,在命令行执行如下命令(还是在项目的根目录下)

2. dotnet-nuget-push

nuget pack Shenba.DemoPackage.Core.nuspec

3. packagesearch.azurewebsites.net

之后会生成一个Shenba.DemoPackage.Core.1.0.0.nupkg文件,这个就是最终要发布的包文件

4. .NET 标准库

实际上这是一个压缩包(把后缀名改成zip),可以用RAR工具查看里面的文件结构,如下图

5. Developing Libraries with Cross Platform Tools

图片 13

6. Target Frameworks

图片 14

7. Porting to .NET Core from .NET Framework

图片 15

可以看到里面包含了常见的lib目录,并且打开后是netstandard1.4目录,然后是具体的程序集文件和XML文档。

10 接下来就是把这个包发布到nuget.org

发布到nuget.org需要使用自己的账号发布,如果通过命令行发布还需要生成自己的一个API key,具体可以参考的说明。

这里给出发布的package的命令行,其中XXXX是注册后得到的API key

nuget push Shenba.DemoPackage.Core.1.0.0.nupkg XXXX –Source nuget.org

11 push之后是不能立即在nuget搜索到的,这跟之前的非.NET Standard的是一样的,不过可以在自己的Account下看到发布的包

图片 16

12 在.NET Core项目中使用刚发布的Demo package

这个跟使用普通的.NET Core的Package一样,修改project.json或者使用界面的package manager引入,比如直接在project.json的dependencies节点加入package的引用

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.1"
    },
    "Shenba.DemoPackage.Core": "1.0.0"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }
}

保存之后当然也会自动的restore,然后会显示在引用中

图片 17

当然代码里调用这个package的类也是没有问题的,调用代码就不说了,就是个示例而已。

13 在.NET Framework 4.6.1的项目中使用该Demo package

一开始提到这个package是基于.NET Standard1.4版本的,根据版本支持图,.NET Framework 4.6.1的项目也是可以引用这个包的。

新建一个.NET Framework 4.6.1的控制台项目,package控制台运行

Install-Package Shenba.DemoPackage.Core

同样也是能正确被引用和调用的,下面是packages.config的内容

<packages>
  <package id="Shenba.DemoPackage.Core" version="1.0.0" targetFramework="net461" />
</packages>

 

小结

以上是创建并发布一个可用于.NET Core(当然也可用于.NET Framework)的Nuget包过程,大致流程跟发布普通的Nuget包相同,但需要注意选择需要支持的.NET Standard的版本。

后续会准备一个更加有意义的.NET Core包,可用于生成ASP.NET MVC Core的学习示例代码。

(目前针对dotnet core项目的nuget包,还不支持执行包里的代码模板和识别Content内容,所以暂时无法实现

详情参考

这个Demo的示例代码路径

编辑:编程 本文来源:目前基础类库均为.NET Framework,Visual Studio中对项

关键词: