(Maybe) best practice: Use shared projects in Visual Studio involved with Nuget

I wrote many solutions in Visual Studio. Some of them includes components, which intend to be published to Nuget.

Previously, I wrote these projects directly and publish them to Nuget. This is not a smooth way. Consider this: You have project A need to be published to Nuget. Project B, as well. Project C need to reference project A and B, and also need to be published to Nuget. Project D need to reference C for testing. Obviously, following Nuget standard, the Project C need to reference A by using Nuget Packages instead of the projects of A and B directly. But it seems that there is no called testing mode publishing in Nuget supported. There is no easy way to test your project before publishing to Nuget. Maybe you need to change the references in Project C and D repeatedly, switching mode between testing and publishing.

Recently, Shared Project support added to Visual Studio. Now I use a better way, IMHO, in developing such a solution mentioned above.

  • Create a shared project for each project need to be published to Nuget.
  • Put all codes into shared project instead of original one.
  • Create a project for publishing to Nuget, reference the shared project related. — Project N
  • Create a project for testing, reference the shared project related. — Project T

If your Nuget projects need more references which will be published to Nuget from this solution, add them from Nuget to the Project N, and add them as reference from their Project T to this Project T.

All Project Ns will only be used for publishing to Nuget. As well as all Project Ts will be used for testing. They share the same code but the different source for referencing.

dotNet Library: Fraction Support

Add fraction support.


Known Issue:

Using an instance built by default parameterless constructor will cause exception or miscalculation. To avoid this, always use parameter-based constructors. This will not be fixed due to consideration about running speed.


Source code: Github

License: MIT

Nuget: SecretNest.TimerFix

Supported platform: NetCore 1, NetCore 2, NetFx 4, NetStd 1.3, NetStd 2.0


A replacement of NetFx Threading.Timer without cumulative error

This is a complete replacement of Threading.Timer. All methods of Threading.Timer are supported. You could use this TimerFix by simply replacing the Threading.Timer object.

Threading.Timer is encapsulated in this class.

In constructors, you could pass the interval setting value. Less the value set, more CPU time is required. Default value is 15 milliseconds.


Source code: Github

License: MIT

Nuget: SecretNest.TimerFix

Supported platform: NetCore 1, NetCore 2, NetFx 4, NetStd 1.3, NetStd 2.0

Hidden Lead Bytes in Thumbprint while copying from Windows

Microsoft digs lots of pits, and I keep jumping among them.

Recently, I wrote a program using HttpClient in dotNet to post some data to server through HTTP Post. The server is set with client certificate required.

My designing is simple:

  1. Open X509Store to query the certificate by using thumbprint.
  2. Attach the certificate found in step 1 into WebRequestHandler.
  3. Pass the handler created in step 2 to the instance of HttpClient and send the request.

Required by step 1, I need to type the thumbprint of the certificate into code. The steps I did:

  1. Open certificate from Windows. It’s shown up like this:
  2. Copy the text of Thumbprint and paste it into a notepad.
  3. Replace all spaces to nothing.
  4. Copy the new text into code.

When I run the code, it ended in a strange way. No certificate is found by using the thumbprint I provided. I dig a long time before I found this pit prepared by Microsoft:
The text, copied from the window above (in step 1), contains hidden lead bytes “0x200E”. These bytes won’t display in code view of Visual Studio, nor in Notepad.

After these removed, problem is gone as well.

Web Deploy for Visual Studio

While I’m trying to deploy my site from Visual Studio to a Windows Server 2012 R2 instance, I have to dig a lot for troubleshooting about Web Deploy related problems.


Here are some not listed in Microsoft documents:

  • Visual Studio need both Web Deploy (Web Deployment Agent Service, MsDepSvc) and Web Management Service (WMSVC).
  • You cannot install Web Management Service separately.
  • The easy way to install the both is choose “Web Deploy 3.6 for Hosting Servers” Web Platform Installer.
  • If you selected “Web Deploy 3.6” in another release, without “for Hosting Servers”, Web Management Service will not be installed.
  • If you leave Web Deploy installed without Web Management Service, you could add it by install “Web Deploy 3.6 for Hosting Servers” but IT WILL NEVER WORK! You have to UNINSTALL existed Web Deploy first and then reinstall the “Web Deploy 3.6 for Hosting Servers”.