A typical MSBuild import stack

In a typical C# project build, the property MSBuildAllProjects  looks like this:

C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props
C:\Users\Ying\Source\ClassLibrary_nuget\ClassLibrary_nuget\obj\ClassLibrary_nuget.csproj.nuget.g.props
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.props
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.DefaultItems.props
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.SupportedTargetFrameworks.props
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.CSharp.props
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.BeforeCommon.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.DefaultAssemblyInfo.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.DefaultOutputPaths.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.TargetFrameworkInference.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.RuntimeIdentifierInference.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.NuGetOfflineCache.targets
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.CSharp.CurrentVersion.targets
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\Managed\Microsoft.Managed.DesignTime.targets
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\Managed\Microsoft.CSharp.DesignTime.targets
C:\Users\Ying\Source\ClassLibrary_nuget\ClassLibrary_nuget\ClassLibrary_nuget.csproj
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Microsoft.Common.targets\ImportAfter\Microsoft.NET.Build.Extensions.targets
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\Microsoft.NET.Build.Extensions.targets
C:\Users\Ying\Source\ClassLibrary_nuget\ClassLibrary_nuget\obj\ClassLibrary_nuget.csproj.nuget.g.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.Common.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.DefaultItems.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.DisableStandardFrameworkResolution.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.GenerateAssemblyInfo.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.ComposeStore.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.CrossGen.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Publish.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.PreserveCompilationContext.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.ConflictResolution.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.CSharp.targets
C:\Program Files\dotnet\sdk\2.1.202\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets
Advertisements

.NET Core: now good cross-platform language

Let’s dive straight in cross-platform development using .NET Core 2.0.

We can have scenario when we want to both use Linux server and .NET Core at the same time, but we also want to stick to development using Visual Studio on Windows (not like other colleague). We can do below:

  • Write a library in VS on Windows
  • Publish the library to Nuget.org
  • Another colleague download my library from Nuget.org and consume it

Now let’s go through these steps in detail.

Write a library in VS on Windows

Create a .NET standard 2.0 library.

01

Publish the library to Nuget.org

Pack your library to a .nupkg file.

02

03

Upload the .nupkg file to Nuget.org, your package repo.

04

Wait for a moment, the package will then be ready for download.

05

Download library from Nuget.org and consume it

Another colleague might have code like below, which consumes your library:

using System;
using shiying;

namespace projects {
    class Program {
        static void Main(string[] args) {
            Helper h = new Helper();
            Console.WriteLine(h.Help(1));
        }
    }
}

He should go to his project dir and run this command to add the library reference:

dotnet add package ClassLibrary_nuge

The reference will be added to .csproj file, and the package will be downloaded from Nuget.org and saved in user’s local cache directory. (~/.nuget/packages/ if you wonder) After it, he can build and run his application successfully.

Useful SQL Server tools in Visual Studio

A less-known fact with Visual Studio is that, core SQL tool set is already included, but hidden, working behind the scenes.

This is convenient for developers because you no longer need to install a separate SQL Management Studio to access local/remote SQL server. For example, if you are developing Azure service using Visual Studio, it is easy-peasy to directly manipulate test data on the cloud through the VS GUI. Here is how to do it:

1. Use Ctrl-Q to search “SQL” or open menu item “New Query…”.

Capture

2. The connection dialog lists all available servers for you to choose: local / network/ Azure

2017-05-17 (1)

3. The opened new window tab resembles what you are used to in SQL Management Studio, Enjoy the query!

Capture

Get table row count – the fast way

How to get row count of a table in SQL Server quickly? Easist way, of course, is “SELECT COUNT(*) FROM <Table Name>”, most of you would say. However, there is another way, even easier and faster, that is “sp_spaceused <Table Name>”. It is shorter, and more importantly, it returns instantaneously when you try to get information of a huge table (millions of lines).

Experiment on a table with 2.8 million rows shows that time spent with COUNT(*) method is 3 seconds. Actual time taken is dependent on your hardware environment.

MSDN link: http://msdn.microsoft.com/en-us/library/ms188776.aspx

A good article explaining how it works: http://www.sqlservercentral.com/articles/T-SQL/67624/