UWP control development-use NuGet to package your own controls and uwp control nuget to package

UWP control development-use NuGet to package your own controls and uwp control nuget to package
Introduction

In the current development, the use of NuGet has gained a considerable position, especially in the UWP development of the application. NET Core, the modular platform itself is directly dependent on the NuGet Package Manager.

Sometimes I have developed a good control component and want to share it with developers through NuGet to enjoy the advantage of fast and modular package manager. What should I do? This article will introduce the process of cooperation between UWP and NuGet in the Development and packaging of basic UWP controls.

 

UWP control development

For the development of controls, we must have been engaged in a hundred battles. However, this article still provides some small suggestions to help you create more universal and easy-to-use controls.

Select the Database Type

For UWP applications, portable class libraries, common UWP class libraries, and Windows Runtime component libraries are acceptable.We recommend that you useWindows RuntimeComponentsTo organize your own controls. Benefiting from the new architecture of WinRT, the compiler will report as long as it complies with the WinRT interface requirements ), components can be used in C # app or C ++/CX app for interaction.

Consider the XAML Layout System

In addition, we have to mention some preparations necessary to make the control easier to use. Previously, we developed the PullToRefresh. UWP control and released it in the form of a NuGet package. Later, we slowly noticed that this control would make the XAML designer in Visual Studio unable to work normally. For this reason, we made some exploration and gained the experience that for newly written controls, the layout of the XAML framework needs to be considered.

The XAML control framework runs through two steps: Measure and Arrange. Events such as SizeChanged are the product of these two steps. VS's XAML designer focuses on the two standard layout flows when analyzing the XAML files written by developers. For events such as Loaded and SizeChanged, if the control writer places the layout operation in it (although convenient, it will actually lead to a new round of layout, which may affect performance ), in addition, the designer sometimes fails to take into account, causing the designer to behave abnormally (the widget's appearance changes, or even the designer crashes ).

The standard controls of XAML do not need to be said. The designer can well parse their XAML layout (in generic. xaml) and the Measure and Arrange procedures they provide. This is why we can see in the XAML designer that the Grid splits the rows and columns according to our definition, and StackPanel automatically distributes sub-items in stack mode. If you write new controls that focus on business, such as updating text display after a certain amount of computing, you don't have to worry about these. However, if the control is more inclined to provide a layout scheme, you cannot ignore this. Therefore, some implementations may cause the designer to work abnormally after the control is referenced,Use Measure/Arrange to compile complex la s as much as possible when writing controls.Instead of relying on layout events. (Of course, simple implementation can be fully implemented in the event)

 

In addition, there is also a small trick, that is, the DesignModeEnabled attribute of the Windows. ApplicationModel. DesignMode class [1. As the name suggests, it is used to determine whether the control is working in actual applications or in the VS designer. Sometimes the layout of the control is very complicated. Oh, the designer is always abnormal. You may wish to make a judgment on this attribute to provide a simplified layout process for the designer.

 

Use NuGet to package control-related files

Generally, a metro control will bring a pile of scattered files, and The XAML layout will be code-behind. The control will also customize and template ......

To enable the NuGet package to work properly in the referenced project, you need to organize various control files compiled according to the correct structure. To facilitate this process, Visual Studio provides an option to select "Generate Library Layout" on the properties-Build page of the control project ",

 

Then build the package, and the correct package structure will be organized in the output directory. (This configuration must also be performed in release)

Note that*. Rd. xmlFile[2]. Sometimes this file exists in the project (under the root directory \ Properties folder), and the referenced project is in the release configuration, you need to call the local. NET native tool chain, this file may be required. If you do not include it in the package, sometimes the compilation of the referenced project fails. This file must be specially processed.Pack with NuGetChapter.

 

Pack with NuGet

The first step of packaging is to get the NuGet program: https://www.nuget.org/

At the same time, a configuration file is required to describe the current package information, that is, the nuspec configuration file. Next, we will use the PullToRefresh. UWP control package as an example. In this example, the configuration file is named PullToRefresh. UWP. nuspec. The basic format is as follows:

<?xml version="1.0"?><package >  <metadata>    <id>PullToRefresh.UWP</id>    <version>0.3.4</version>    <title>PullToRefresh.UWP</title>    <authors>MS-UAP</authors>    <owners>MS-UAP</owners>    <projectUrl>http://www.cnblogs.com/ms-uap/p/4814507.html</projectUrl>    <requireLicenseAcceptance>false</requireLicenseAcceptance>    <description>Generic Pull Down to Refresh implementation for UWP.</description>    <copyright>Copyright 2015</copyright>    <tags>UWP XAML</tags>  </metadata></package>

 

Of course, there are other ways to create this file, such as creating from the Assembly, directly associating with the project, and so on. Here we use the simplest method. For other methods, see NuGet help document [3].

Then we need to create some directories in the folder where nuspec is located to indicate the platforms supported by the NuGet package:

. \ Lib \ uap10.0Indicates the UWP platform.

Copy the original VS file to. \ lib \ uap10.0.

 

Special Handling of *. rd. xml:

First, the project name folder (. \ lib \ uap10.0 \ PullToRefresh. UWP) to create a Properties folder and put rd. put the xml file there (if this file exists ).

 

After all, the structure of the files to be packaged is as follows:

│ PullToRefresh. UWP. nuspec │ ─ ── lib ‑uap10.0 │ PullToRefresh. UWP. pri │ PullToRefresh. UWP. winmd │ ─ ── PullToRefresh. UWP │ PullToRefresh. UWP. xr. xml │ Sampled-Properties │ PullToRefresh. UWP. rd. xml (requires additional processing) │ emerge-Themes Generic. xbf

 

In the folder where nuspec is located, Run "nuget pack PullToRefresh. UWP. nuspec" on the command line to generate an NuGet package in the current directory! Then you can upload it on the NuGet website.

 

Learn about the NuGet directory

In this example, only one lib folder is created. In fact, NuGet also supports directories such as build, ref, and runtimes in the standard. Here we will give you a brief introduction and provide some inspiration for different application scenarios:

• Lib directory: the most basic directory, including the Assembly and other components required by the referenced project.
• Build Directory: used to store configuration files related to MSBuild. Normally, this directory is rarely used. However, you can use this feature to implement some special functions, such as printing Hello World in the output window during compilation :).
• Ref Directory: A special directory used to provide common interface information for the compiler. It is more intuitive to say that it can change the smart prompts of VS and hide some interfaces. Without this directory, the lib directory actually acts as an interface information provider, and of course also provides implementation. In general, this directory is completely unavailable.
• Runtimes Directory: This directory is related to the CPU architecture. If it is a control developed by C ++ \ CX, we need to use this directory. The lower-level Directory Name of the Runtimes directory must be a runtime identifier, such as a win-x86 or win8-x86. For more information, see http://docs.nuget.org/create/uwp-create#runtimes.

For more information, see NuGet directory structure description [4].

P.S. because native dll must be copied to the running file directory, in addition to automatically copying through the runtimes directory, you can also add the MSBuild configuration file in the build directory, for example, tell the compiler platform where the related files are:

<Target Name = "xxx" BeforeTargets = "ResolveAssemblyReferences"> <ItemGroup Condition = "'$ (Platform)' = 'x86 'or' $ (Platform) '= 'x64' or '$ (Platform)' = 'arm' "> <Reference> <HintPath> includes $ (Platform) </HintPath> </Reference> </ItemGroup> </Target>

 

C #The compiled library, because it is a hosting code, we can directly configure it to generate AnyCPUType assembly or WinRTComponent, and directly place the compiled file in lib \ uap10.0 \. Our PullToRefresh. UWPThis is the case in the example.

 

Reference

[1] DesignMode class: https://msdn.microsoft.com/library/windows/apps/br224664

[2] Runtime Directives (rd. xml) configuration file: https://msdn.microsoft.com/en-us/library/dn600639 (v = vs.110). aspx

[3] NuGet create package: http://docs.nuget.org/Create/Creating-and-Publishing-a-Package

NuGet directory structure description: http://docs.nuget.org/create/uwp-create#directory-structure