Target nuget packege for multiple framework

When you’re building a .Net liibrary you have to take in care which framework the end user will use. In order to avoid user’s framework upgrade/downgrade we must target multiple frameworks in the nuget package.

Library project configuration

First, in your .csproj file, create separate build configurations. I created “Debug” | “Release” and “Debug45” | “Release45” for the target frameworks 4.6.1 and 4.5 respectively. I manually set the OutputPath and added theTargetFrameworkVersion element to each configuration:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug45|AnyCPU'">
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release45|AnyCPU'">

In this way you can build the library with different target framework.

Targeting Multiple Frameworks in NuGet

In the folder created for the nuget package divide the lib folder by adding for each targeted framework the relative folder where you will add the relative library .dll file.

The lib folder looks like this:

  • lib
    • net45
    • net461

Now you can run nuget.exe pack MyAssembly.nuspec

A new package is created.

When you refer this package through Nuget package manager from a VS solution, your reference automatically link the dll related to your project framework.


Nuget: How to reinstall and update packages

There are a number of situations when you need to reinstall and update nuget packages for a VS project.

One of this situations is when you wanna upgrade or downgrade the .NET Framework.

In this situation the most important Nuget functionality is Reinstalling packages with dependencies:

Update-Package –reinstall

reinstalls the same version of the original package, but installs the latest version of dependencies unless specific version constraints are provided. This allows you to update only the dependencies as required to fix an issue. However, if this rolls a dependency back to an earlier version, you can use

Update-Package <dependency_name>

to reinstall that one dependency without affecting the dependent package.

For more informations please visit:

Entity Framework enable migration based on DbContext situated in another project

In order to create a new locally database to run tests you can create your migrations in the test project by taking in care that you can use your repository db context in another VS project.

To achieve this result you can do the following in the Package Manager Console

Enable-Migrations -ContextProjectName MyProject.Repository -ContextTypeName MyProject.Repository.MyDbContext -ProjectName MyProject.Tests -StartUpProjectName MyProject.Tests -ConnectionStringName "MyConnectionString"
Add-Migration "Init Test Db"
Update-Database -ProjectName MyProject.Tests -StartUpProjectName MyProject.Tests -ConnectionStringName "MyConnectionString"

.Net Continuous Integration via Jenkins

This post show a simple and effective way to setup a continuous integration server and a way to update a test environment on each commit on a developer branch.

Our domain is a compositions of these elements:

  • .NET Solution (the project)
  • Git repository (Stash)


We want to create e new continuous integration environment using Jenkins to build .NET solutions.


  • Jenkins introduction and installation
  • Configure Jenkins
    • Install Plugins
  • Manage Jenkins settings
  • Create a new Job
    • Set Source Control
    • Build Triggers
    • Build: create a custom script in order to create a package that can be deployed
  • Automatically FTP Deploy via Jenkins
  • Automatically run a new “build and deploy” after a commit on the develop branch.

Jenkins introduction and installation

What is Jenkins?

Jenkins is an application that monitors executions of repeated jobs, such as building a software project or jobs run by cron. Among those things, current Jenkins focuses on the following two jobs:

  • Building/testing software projects continuously. In a nutshell, Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
  • Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong.

For more details (

Download Jenkins


Before installing Jenkins you must download and install Git.

For the most part, you’ll select command-line setting, with the exception of Git command line stuff. In that case, select “use git from the Windows Command Prompt,” as shown below.


Now you can install Jenkins.

The install wizard will open the Jenkins web page.


Configure Jenkins

Install Plugins

Without these required Plugins you will not be able to build and test .NET solutions. In order to add essentials plugins you must go to “Manage Jenkins” > “Manage Plugin”


Required Plugins:
  • The Build Plugin we’ll be using is MSBuild this allows us to build a .NET solution.
  • The GIT Plugin – This plugin allows use of Git as a build SCM.
  • Testing plugin (You’ll need one of these depending on your chosen test framework)
    • MSTest Plugin – This plugin converts MSTest TRX test reports into JUnit XML reports so it can be integrated with Jenkins JUnit features.
    • NUnit Plugin – This plugin allows you to publish NUnit test results.
    • xUnit Plugin – This plugin makes it possible to publish the test results of an execution of a testing tool in Jenkins.
    • Gallio Plugin – This plugin makes it possible to publish Gallio/MbUnit test results.

Tick the check box next to each of the required Plugins and then click the ‘Download now and install after restart’ button.

Optoinal Plugins
  • Green Balls – Changes Hudson to use green balls instead of blue for successful builds. Who doesn’t want Green Balls!
  • Active Directory Plugin – With this plugin, you can configure Jenkins authenticates the username and the password through Active Directory.

Manage Jenkins settings

Go to “Manage Jenkins” > “Configure System”


Enter and go to the Git section and set the fields with your current Git installation described above.


After that you must config the “MSBuild installations …” (click to open)



Please select your own path for MSBuild.exe

Click Save.

Create a new Job

In Jenkins the definition of a build process is called a Job. Jobs are created using the main menu on the Jenkins home page. We’ll create a basic Job that will checkout our source and build the solution.

From the main Jenkins menu, Click the ‘New Item’ link.


You now see the New Job configuration page.

Set your own name (Test in this case) and select “Freestyle Project” and select “Ok”


Jenkins will now create the Job workspace on disk and redirect you to the job configuration page.

Next we’re going to checkout our solution from source control and build it. So we first need to give Jenkins details of our source control server.

Set Source Control

For the purpose of this demo we’ll use Git.

Lets setup our Job to grab the source code from this repository. This is done in the” Source Code Management” section of the configuration page.


  1. Select the Git radio button.
  2. Provide the git project url ang give the right username/password entry in order to connect Jenkins to the repository.

If can create a new user by clicking the aside “Add” button to do this.

After taht you can change the “Branches to build”. We choose to check-out the develop branch.

Git is now configured and we can move onto Build Triggers.

Build Triggers

We want to trigger a build every time our source code changes; we achieve this by creating a “Build Trigger” which polls our source code repository. When a change is detected a new build is triggered and a new deployable package is generated.

Under the Build Triggers section, tick the Poll SCM checkbox.


By clicking on (?) you will read more about the configuration instruction for the “Schedule” field. These are the instruction:


This field follows the syntax of cron (with minor differences). Specifically, each line consists of 5 fields separated by TAB or whitespace:

MINUTE Minutes within the hour (0–59)
HOUR The hour of the day (0–23)
DOM The day of the month (1–31)
MONTH The month (1–12)
DOW The day of the week (0–7) where 0 and 7 are Sunday.

To specify multiple values for one field, the following operators are available. In the order of precedence,

  • * specifies all valid values
  • M-N specifies a range of values
  • M-N/X or */X steps by intervals of X through the specified range or whole valid range
  • A,B,...,Z enumerates multiple values

To allow periodically scheduled tasks to produce even load on the system, the symbol H (for “hash”) should be used wherever possible. For example, using 0 0 * * * for a dozen daily jobs will cause a large spike at midnight. In contrast, using H H * * * would still execute each job once a day, but not all at the same time, better using limited resources.

The H symbol can be used with a range. For example, H H(0-7) * * * means some time between 12:00 AM (midnight) to 7:59 AM. You can also use step intervals with H, with or without ranges.

The H symbol can be thought of as a random value over a range, but it actually is a hash of the job name, not a random function, so that the value remains stable for any given project.

Beware that for the day of month field, short cycles such as */3 or H/3 will not work consistently near the end of most months, due to variable month lengths. For example, */3 will run on the 1st, 4th, …31st days of a long month, then again the next day of the next month. Hashes are always chosen in the 1-28 range, so H/3 will produce a gap between runs of between 3 and 6 days at the end of a month. (Longer cycles will also have inconsistent lengths but the effect may be relatively less noticeable.)

Empty lines and lines that start with # will be ignored as comments.

In addition, @yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly are supported as convenient aliases. These use the hash system for automatic balancing. For example, @hourly is the same as H * * * * and could mean at any time during the hour. @midnight actually means some time between 12:00 AM and 2:59 AM.


# every fifteen minutes (perhaps at :07, :22, :37, :52) H/15 * * * * # every ten minutes in the first half of every hour (three times, perhaps at :04, :14, :24) H(0-29)/10 * * * * # once every two hours every weekday (perhaps at 10:38 AM, 12:38 PM, 2:38 PM, 4:38 PM) H 9-16/2 * * 1-5 # once a day on the 1st and 15th of every month except December H H 1,15 1-11 *
Finally we just need to tell Jenkins how to build the solution when changes are detected. This is done via the “Add build step” button under the Build section.

Build: create a custom script in order to create a package that can be deployed

We want to reach this goal: provide a visual studio solution ==> generate a build ==> run tests* ==> create a publish package ==> deploy via ftp.

* not included yet in these guide.

In order to accomplish these steps we start from “Add build step” and in this instance select “Execute Windows batch command”.


The publish.bat script in our case make these steps:

  • set path variables for project, destination foldert, etc.
  • build the .NET solution with a specific configuration (Test, Release, etc.)
  • copy the created package into a destination folder in order to be moved via FTP on a specific Test server.
set msBuildDir=C:\Program Files (x86)\MSBuild\12.0\Bin
set slnPath=C:\myProjectSolutionPath
set packagePath=C:\myProjectSolutionPath\Project.Web
set deployPath=C:\DEPLOYED_APPS\ProjectName

rd %deployPath%\CI_Release /S /Q
md %deployPath%\CI_Release

call %msBuildDir%\MSBuild.exe  %slnPath%\myProject.sln /p:Configuration=Release /l:FileLogger,Microsoft.Build.Engine;logfile=Manual_MSBuild_ReleaseVersion_LOG.log

XCOPY %packagePath%\obj\Release\Package\PackageTmp\* /S %deployPath%\CI_Release\

Automatically FTP Deploy via Jenkins

… Coming soon …

Create a NuGet package for a C# library

In this article we discuss a simple way to create, configure and publish your first c# library through personal NuGet repository.

  • Download NuGet.exe from
  • Add environment variable path that refer the installed nuget.exe file
  • Build your project in Release mode
  • Get the “bin” folder path where you can retrieve the project assembly
  • Move under your project bin/release folder and copy the generated *.ddl (pay attention: copy only your project assembly file and not all the dependencies) and paste in a new different folder
  • In this folder create these two folders:
    • lib – contains only the project dlls
    • content – contains all the solution content after the build process (Release mode) without the “bin” and “obj” folders
  • Open cmd with admin priviledges:
    • move under the temp folder where you create the folder at the step above
    • enter in the lib folder (> cd lib)
    • run > nuget.exe spec MyAssembly.dll
    • this creates a Nuspec file
    • move the .nuspec file outside the lib folder
    • you must now have this configuration inside the folder:
      • content
      • lib
      • MyAssembly.nuspec
    • edit the NuSpec file as needed (see the section below)
    • then run > nuget.exe pack MyAssembly.nuspec
    • a new MyAssembly.nupkg was created.

Nuspec file configuration

<?xml version="1.0"?>
<releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
<copyright>Copyright 2015</copyright>
<tags>Tag1 Tag2</tags>
<dependency id="Newtonsoft.Json" version="7.0.1" />
<dependency id="NLog" version="4.2.1" />
<dependency id="NLog.Config" version="4.2.1" />
<dependency id="NLog.Schema" version="4.2.1" />

In the .nuspec file you can configure all the dependencies that you dll requires. In this way the NuGet repository can download the dependencies when a client install your NuGet package.

Now you can provide this package and retrieve via Visual Studio as all the other libraries.

Windows 10 critical error: Start menu and Cortana doesn’t work

In order to fix the “Start menu and Cortana” error you must do the following steps:

  1. Open Task manager
  2. Click on File > Run new task
  3. Write PowerShell
  4. Write this command on PowerShell prompt: “Get-AppXPackage-AllUsers|Foreach{Add-AppxPackage-DisableDevelopmentMode-register”$($_InstallLocation.)\AppXManifest.xml”}”
  5. Close the PowerShell window and restart the computer.