. NET: to talk about the use of Shared projects, sharedproject

. NET: to talk about the use of Shared projects, sharedproject

From Visual Studio 2015, Shared projects are added to the Project template list as a new Project type, its main purpose is to enable code or resources to be shared among multiple different types of projects. It is much more flexible than its predecessor PCL (Portable Class Library. Because Shared projects share code or resources and do not create separate assemblies, while PCL is a Shared assembly that needs to be compiled separately and will generate separate assemblies.

In projects, using Shared Project can help us easily solve some problems. This article mainly discusses how to use it during development and what problems it can help us solve. Before that, let's first look at how to create and use a Shared Project.

Create and use

As mentioned above, Shared Project is a type of Project template, so we can create a new Project in the existing solution, and then select Shared Project in the Project template list:

In this Shared Project, we can add all the code or resources (slice, Html file, JS file, etc.) that need to be Shared with other projects ). In addition, to keep it consistent with the existing project namespace, you can right-click it in solution manager and select Properties to change its Root namespace.

Next, add references to those projects that need to reference it, as shown below:

When referenced, all codes and resources in Shared projects can be used normally in these projects.

In addition, Shared Project cannot be compiled by itself. We need to compile and reference its Project to generate exe, dll, and other assembly. In addition, the Shared Project itself will not be output as an assembly.

Scenario 1: output class libraries for different. NET Framework versions

If you are developing a class library or framework and finally want to release it so that others can use it, your class library may need to meet multiple requirements. NET Framework Version, such as 2.0, 3.5, 4.0, and 4.5. Since the later version of the Framework adds more APIs and more syntaxes, it makes code compilation easier, for example, it is not supported in lower versions, so the code in the class library needs to be differentiated by different versions.

In this case, the above problem can be solved by using the Shared Project and Conditional compilation symbol (Conditional compilation symbols. We can do this:

1. Create a Shared Project;
2. Create multiple Class Library projects respectively, and specify different framework versions for their Target Framework;
3. Set different Conditional compilation symbols for each Class Library category (set in the "compile" tab of the Project attribute), such as NET2_0/NET4_0/NET4_5;
4. Then, you can use these symbols in the Shared Project to determine the Framework version and write code for different versions, such as the following code (note the bold part ):

            this.windowChrome = new WindowChrome            {#if NET4_5                ResizeBorderThickness = SystemParameters.WindowResizeBorderThickness, #else                ResizeBorderThickness = SystemParameters2.Current.WindowResizeBorderThickness,#endif                CaptionHeight = 0,                CornerRadius = new CornerRadius(0),                GlassFrameThickness = new Thickness(0),                UseAeroCaptionButtons = false            };

Scenario 2: output class libraries for different platforms

If one (or more) class libraries in the project need to support two different platforms, x86 and x64, so that the software can run on both x86 and x64, shared Project can also be used in this case.

A specific example is to develop Office Add-ons. If your add-ons are of the COM type, you must provide the corresponding versions for 32-bit and 64-bit Office respectively. For 32-bit, the target Platform (Platform target) of the Assembly can be Any CPU, but for 64-bit, it should be x64.

Using Shared Project can easily solve such problems. Specific Practices:

1. Create a Shared Project for the add-on and put all the code and resource files into the Project;
2. Create two different Class libraries to reference Shared projects. The difference is that the target platforms of these two projects are different. One is Any CPU, and the other is x64;
3. If a third-party library is used, add the same reference for the two projects;
4. In addition, you must modify their assembly names so that their output Assembly names are different and meaningful.

Finally, you must note that when modifying project properties, whether it is to set the "Conditional compilation symbol" or to modify the "Target Platform ", note that both of them are associated with the project configuration (Debug/Release). That is to say, they have been changed in the Debug configuration, but also in the Release configuration; for this, an alternative is to select "All configurations" from the configuration drop-down list and then set the symbol or target platform, which will be effective for Debug/Release.

Summary

This article mainly discusses the use of Shared Project and its actual use scenarios. It enables our Assembly to be oriented to different. NET Framework versions and different platforms. In fact, it is not hard to see that this is implemented by modifying the project attributes. In this way, multiple projects can achieve the same code and different assembly attributes, thus solving the actual corresponding problems. If you encounter a similar problem during the development process, you can try to use Shared Project to solve it.