.Net Core 2.0: project.assets.json’ doesn’t have a target for ‘.NETStandard,Version=v2.0’

The Problem

Odd error when building a .net core project with Visual Studio Code. This built a few weeks ago – went back it it and I’m getting this

C:\Program Files\dotnet\sdk\2.0.0\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(165,5): error : Assets file ‘myproject\obj\project.assets.json’ doesn’t have a target for ‘.NETStandard,Version=v2.0’. Ensure that restore has run and that you have included ‘netstandard2.0’ in the TargetFrameworks for your project. [myproject\MyProject.csproj]

.Net Core has been installed, it used to work and there is not much on the Internet. Bafflement.


Turns out the bin and obj folders for each of the project need to be manually deleted. Once done then the command

dotnet build

gave me the green light and normal service has been resumed. No idea what it going on but sorted now – so I thought I would take a minute and post the solution to my small corner of the Internet. Cheers.

Multiple Projects with .Net Core and Visual Studio Code

The challenge is to create a solution in VS Code with multiple projects. There are three projects

  1. A console application
  2. A web api application
  3. A library with data access code that is common to both.

It will look like this when we are finished

Expanded to show detail

We need a solution that can build out all these projects in one click. Since we using VS Code and enjoying it’s lightweightness we’ll be relying completely on the new .Net Core Command Line Interface. I enjoy a challenge so using the command line seems fun (to me). Let’s go.


In case you don’t want to read the detail – the commands used to set up all projects, solutions and references are

From project root

dotnet new console -o Demo.ConsoleApp

dotnet new classlib -o Demo.Common

cd Demo.ConsoleApp

dotnet add reference ../Demo.Common/Demo.Common.csproj

dotnet add package MyPackage

cd ../

dotnet new webapi -o Demo.Api

cd Demo.Api

dotnet add reference ../Demo.Common/Demo.Common.csproj

cd ../

dotnet new sln -n Demo

dotnet sln add Demo.ConsoleApp/Demo.ConsoleApp.csproj

dotnet sln add Demo.Api/Demo.Api.csproj

dotnet build


To do this you’ll need VS Code’s C# extension installed into visual studio. Go to extensions and search for C#.

Install and away you go.

Note on command line

All .Net Core CLI commands can be entered into the terminal window in VS Code or into the standard command prompt if you prefer. Navigate to the root folder and enter your first command

Create Console Application

dotnet new console -o Demo.ConsoleApp

This installs our console application project. Since we are on .Net Core 2.0 we get the csproj file rather than the json project file of earlier versions. This installs the console app in a new folder with the same name as it’s containing folder. If we want a different name to the folder we do that by

dotnet new console -n MyProjectName -o Demo.ConsoleApp

But we don’t want that. We are keeping it simple. What I like about .Net Core is that it’s had all the gubbins stripped out. So our proj file for the console app is simply …

<Project Sdk="Microsoft.NET.Sdk">
    <ProjectReference Include="..\Demo.Common\Demo.Common.csproj" />

Nice. I understand that.

Create Common Library

Next we want to create a C# dll to host some common code like data access.

dotnet new classlib -o Demo.Common

Creates an empty project called Demo.Common with a nice simple proj file thus

<Project Sdk="Microsoft.NET.Sdk">

Link Common Library to Console app

Change to the console app direct and run the add reference common

cd Demo.ConsoleApp
dotnet add reference ../Demo.Common/Demo.Common.csproj

Inserts the following into the console proj file

    <ProjectReference Include="..\Demo.Common\Demo.Common.csproj" />

So the console app can access code in the common project and the two will build out together.

Add Nuget package to Common Library

We commonly want to add some nuget packages to our projects. So lets add the HtmlAgility pack and a C# driver for MongoDB – no reason for them other than I often use them.

Change directories back to common library

 cd ../Demo.Common

Now add the packages

dotnet add package MongoDB.Driver
dotnet add package HtmlAgilityPack

Look at the proj file and you can see the package references inserted

<Project Sdk="Microsoft.NET.Sdk">
    <PackageReference Include="HtmlAgilityPack" Version="1.6.5" />
    <PackageReference Include="MongoDB.Driver" Version="2.4.4" />

VS Code likes to tell me to restore the project I.e. run dotnet restore. You don’t need to. Dotnet build or dotnet run does it for you.

Build Console Application

Let’s check things are working as they should and build our console app.

cd ../Demo.ConsoleApp
dotnet build


  Demo.Common -> C:\development\Demo\ASP.NET Core\MultipleProjects\Demo.Common\bin\Debug\netstandard2.0\Demo.Common.dll

Demo.ConsoleApp -> C:\development\Demo\ASP.NET Core\MultipleProjects\Demo.ConsoleApp\bin\Debug\netcoreapp2.0\Demo.ConsoleApp.dll

Build succeeded.

0 Warning(s)

0 Error(s)

Good – by building the project we get both common and the console application building.

Create API 

Return to root folder

cd ../

Now add a web api project called Demo.Api

dotnet new webapi -o Demo.Api

Change to the Api folder

cd Demo.Api

Now add a reference to our common library

dotnet add reference ../Demo.Common/Demo.Common.csproj

The Api proj file looks a bit more complex but I’ll still pretty minimal compared to Visual Studio proj files.

<Project Sdk="Microsoft.NET.Sdk.Web">
    <Folder Include="wwwroot\" />
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
    <ProjectReference Include="..\Demo.Common\Demo.Common.csproj" />

Now let’s build that project. Staying in the Api folder

dotnet build

And the output shows us two projects have been built.

  Demo.Common -> C:\development\Demo\ASP.NET Core\MultipleProjects\Demo.Common\bin\Debug\netstandard2.0\Demo.Common.dll

Demo.Api -> C:\development\Demo\ASP.NET Core\MultipleProjects\Demo.Api\bin\Debug\netcoreapp2.0\Demo.Api.dll

Build succeeded.

0 Warning(s)

0 Error(s)

Joining everything together

Ok , so we want all the projects to build in one click. Because we have two independent applications (an API and a console app) we aren’t going to be able to do the build by navigating to a folder and building the proj file. We need a solution file to bind them all together

(this shamefully baffled me for a while. I was trying all sorts with launch.json etc… The solution is obvious though – embarrassed for not getting it immediately)

Back to root

cd ../

Now add the solution file. We don’t want it in it’s own directory so omit the -o parameter. Add in the -n otherwise it takes it’s name from the containing folder which we don’t want in this case.

dotnet new sln -n Demo

Now include the API and Console app

dotnet sln add Demo.ConsoleApp/Demo.ConsoleApp.csproj
dotnet sln add Demo.Api/Demo.Api.csproj

The solution file now includes the project info

Microsoft Visual Studio Solution File, Format Version 12.00

# Visual Studio 15

VisualStudioVersion = 15.0.26124.0

MinimumVisualStudioVersion = 15.0.26124.0

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Demo.ConsoleApp", "Demo.ConsoleApp\Demo.ConsoleApp.csproj", "{FDFFDD15-D0C0-4D66-9694-B21D85DBA5AE}"


Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Demo.Api", "Demo.Api\Demo.Api.csproj", "{C1B9391B-07FC-403A-AA46-41128BC1FD07}"


Staying in the solution directory run build

dotnet build

And now all three projects are built.

Demo.Common -> C:\development\Demo\ASP.NET Core\MultipleProjects\Demo.Common\bin\Debug\netstandard2.0\Demo.Common.dll

Demo.ConsoleApp -> C:\development\Demo\ASP.NET Core\MultipleProjects\Demo.ConsoleApp\bin\Debug\netcoreapp2.0\Demo.ConsoleApp.dll

Demo.Api -> C:\development\Demo\ASP.NET Core\MultipleProjects\Demo.Api\bin\Debug\netcoreapp2.0\Demo.Api.dll

Build succeeded.

0 Warning(s)

0 Error(s)


Demo code

The rather uninspiring skeleton demo app is at

More interesting the same pattern is on a .Net Core API for some Buddhist texts I’ve been working on


Is the console app that parses HTML and populates a document database with the texts

Is the web api to access the texts

Is the model and repositories common to both.  It’s the same pattern as the simplified demo app and I’m using VS Code for that – just to try it out really.

Useful Links

Full documentation for .Net Core Command Line Interface

Visual Studio Code is freely available here.

Resharper Build and Run

Just a quick shout out for Resharper’s new build and run feature. I’ve become accustomed to Resharper slowing my machine up as it endlessly loads a variety of caches and processes. Speaking as a member of the slower development machine community it is a delight to see a new feature that actually speed things up and increases productivity even on less than optimal machines. Build and run uses some heuristics (i.e. clever workings out) to analyse which projects actually need to be built then only builds these. On first build you don’t notice much of a difference but on subsequent build it makes for dramatic increases of speed. It’s impressive and a real benefit.

I won’t bore too much with my current slow machined troubles but I currently a home based contractor working on a mid range laptop – I anticipated this laptop to be used for some lightweight home development projects. Inside it’s running 2 Visual Studio instances with 35 and 12 projects each respectively. Really it can’t cope – except it suddenly can using Build and Run. 5 minutes build times have become 10 second affairs. It’s not too much to say that it has been a bit of a life (job) saver.

Of course the real solution is to buy a better machine. But as I find myself in a new, more expensive country funds are a little short right now. So until I spring for a new laptop, Resharper Build and Run is keeping me afloat. Thanks guys.


I’ve actually now done the decent thing and upgraded my laptop to use a 500GB SSD disc and popped in some extra RAM while I was at it. It runs like a dream. I close down and reopen Visual Studio now just for the fun of it – takes seconds. I still like Resharper Build and Run though, but it’s now less critical to my health and well being.

Dealing with invalid js characters in VS Code

Even though mental stability is core personal principle that is rarely violated, here is something that was driving me mad recently.

The Problem

I was using VS Code do write a demo AngularJS application and I kept getting this error in my JavaScript files

[js] invalid character

With funny red squiggles thus

There was no rogue comma or strange character visible and no amount of deleting would resolve it. I’m more used to Visual Studio where odd things happen fairly frequently and this kind of thing can be ignored while the environment catches up with itself. However this floored VS Code and my lovely demo app just stop working. It was happening all the time. Bah!!

The Investigation

Although it isn’t visible in VS Code, the rogue character is visible in Chrome developer toolbar.

Press F12 -> Select Sources -> Navigate to the broken js file

The dodgy character is visible as a red dot and the character can be identified by hovering over it

In this case the character is


\u donates Unicode and the 7f is hexadecimal so converting to decimal the character is 127. Looking this up on an ASCII table we find out it is a [DEL] character.

The Solution

Once the culprit is identified it’s an easier matter to use this regex


to find and replace the rogue character and replace it with an empty string. Don’t forget to do a regex search in VS code – select the star icon in the search box as show below. This fixes the application and thus repairs my fragile mental state.

Why delete characters keep occurring in my JavaScript code is anyone’s guess. It could be a VS Code quirk but I’ve googled around it and haven’t found anything. It could be me flailing around with my new laptop and somehow inserting odd characters into files. I guess some things we aren’t meant to know.

Useful links

How to write regex to find Unicode. The important point to remember is that it must contain 4 hexadecimal digits. So \u7f does find my DEL character – the regex needs to be padded out to \u007f

Download page for VS Code. Recommended.


Why Doesn’t My Visual Studio Solution Build? A Troubleshooting Guide

broken building

I’m pretty good at getting Visual Studio projects building correctly – I’m a bit of a Visual Studio whisperer. In one job I could get the ‘flag ship’ application up and running on a new machine in half the time of anyone else – that still meant half a day’s work. Strangely that’s not on my CV.

So here are the steps I go through to get a rogue project building in Visual Studio. These steps range from the basic to the bizarre. They are in the order I would do them and by following them I can pretty much get any Visual Studio project back on track. So put on your tin hat and let’s get that errant Visual Studio solution building.

Sanity Check

Before embarking on a full blown Visual Studio troubleshooting endeavour it’s best just to do a few simple checks.

Have you got latest code?

Everybody has wasted hours trying to get an old version of the code working. I still do it. The developer that sits opposite me still does it. My boss still does it. Don’t do it. Get the latest version of the code from your repository.

Does it build for other people in your team?

Just see if other people are having the same problem. If you have continuous build – check that is still working and running through cleanly. The code might not work for anyone. More illuminating – it might work for some at not others.


Every few weeks you will probably be faced with a non-building Visual Studio project. Here are some basic steps to help. These will probably be enough.

Clean and rebuild

clean solution

Go to

Solution Explorer -> Right Click -> Select Clean -> Wait -> Select rebuild

Often the bin directories have gone all wonky and are full of junk. Who knows what has happen to them. Clean and rebuild will refresh them and often work when a normal build doesn’t. Standard stuff – but then we are just beginning.

Build each project individually

Often you are faced with mountains of errors which is misleading. It could be one of your low level library projects that is failing to build and causing all other projects to fail. Rebuild each project individually starting with the low level ones that are dependencies for others. Sometimes that’s enough to get the entire solution building. At a minimum, you will better be able to see where the actual issue is and not be swamped by a heap of irrelevant error messages.

Close and reopen Visual Studio

It’s time to restart your Visual Studio. Don’t leave this till the end – it is often the problem. Turn it on and off again – it might help.

As a note – in my experience restarting your computer rarely helps. By all means try it but don’t be surprised when the solution still stubbornly refuses to build.

Manually delete all bin folders

This is really worth a try if you are working with an application with language variants. The language specific resource (e.g. Messages.fr-CH.resx) files compile down into satellite resource files in your bin folder that are contain in their own subfolder e.g.


Weirdly Visual Studio Clean can leave these satellite assemblies behind. Your application will still build but it can cause changes in languages variants not to shine through.

This might seem like an edge case but this exact thing kept a colleague of mine baffled for 6 hours. It was a very emotional moment when we finally sorted it out. So this is very much worth a try.

Start Visual Studio in admin mode

run as administrator

I’m master of my own machine (i.e. I’m a local admin) and I’ve got my Visual Studio set to always open as an administrator. You might not. Right click and run as administrator.

If it isn’t possible get someone who is an administrator to open Visual Studio on your behalf. Then complain bitterly about not being a local admin or your own machine – you are a developer; you really should be.

Have you got bad references?

bad references

Just check all projects and make sure that the references are all there. Look out for the little yellow triangle. If you have bad references then jump to section below dealing with that.

Check IIS

This isn’t relevant for all projects but if you are building a web project using IIS then it’s worth doing checks around that. Obviously it’s a completely legitimate setup to use IIS Express. In that case this isn’t relevant.

IIS pointing at the wrong folder

This is often a problem when changing branches. Visual Studio normally makes a good job of switching for you but not always. If you are hooked up to the wrong folder then your project will build but you won’t be able to debug it. Also changes that you are convinced you are made won’t shine through. This has driven me crazy before.

IIS explore folder

To check

  1. Open IIS (run -> inetmgr)
  2. Navigate to website
  3. Press explore and confirm you are where you think you should be. You might not be in Kanas anymore.

Permissions on app pool

This won’t manifest itself as a build failure but the project won’t be running as expected particularly when accessing external resources. It might be worth checking what the app pool is running as.


application pool settings

To check

  1. Open IIS (run -> inetmgr)
  2. Application Pool -> select the one for the website
  3. Advanced settings

You can now check the user.

The application pool runs under ApplicationPoolIdentity by default. What I’ve sometimes seen is that it’s been changed to a normal user whose password has expired. This is typically fallout from previous Visual Studio failures echoing through the ages.

Bad references

bad references

If you are noticing a yellow triangle on your project references then Visual Studio can’t find a dependency. Sometimes there is no yellow triangle and all looks fine but it still can’t find the dependencies.

With the advent of nuget this is less of a problem now but it does still happen. There are instances where incorrect use of nuget makes it worse and more baffling.

Check reference properties

Go to the references -> right click -> properties

references properties

There are two things to look for

  1. Is it pointing to where you think it should be? It might not be
  2. Copy Local. Bit of witchcraft but I always set this to copy local. It will copy the dll into the bin folder so at least I can satisfy myself that it has found it and is copying it through OK.

Have you checked in the packages folder – don’t!

Even if you are using nuget your bad reference problem might not be at an end. Checking in the packages folder can cause the references not to be found. This is especially baffling since looking at the reference properties reveals no problems. The path to the required dlls is definitely valid and the dlls are definitely there. But it cannot be found – frustration and finger biting.

To resolve delete the packages folder then remove the folder from source control. Rebuild and all will be well.

Resetting Visual Studio

Resetting Visual Studio can (probably will) cause your environment to lose all your custom defaults – so all your shortcuts, settings perhaps plugins will go. Therefore I’ve left this step towards the end as it is not without consequences. That said it is often the resolution so it’s not a bad idea to do it earlier in the ‘what on earth is going wrong with Visual Studio’ resolution process.

Delete all temporary and cache files

This was a fix that often worked in slightly older versions of Visual Studio. I’m using VS 2015 currently and this often isn’t a problem. Still it is worth clearing out these folders and rebuilding

C:\Users\{user name}\AppData\Local\Microsoft\WebsiteCache

C:\Users\{user name}\AppData\Local\Temp

Delete project setting files

Your user settings for a project are stored in files with the extension *.csproj.user i.e


It’s worth deleting all those and rebuilding so reset user specific settings. Also if you have these checked into source control then remove them. They are specific to you and shouldn’t be in a shared repository.

Reset Visual Studio on the command line

When Visual Studio appears utterly broken and you are reaching for the uninstall button, this can often help. It takes Visual Studio back to its initial settings you will need to reapply any custom settings that you have.

Close VS then in a command prompt go to the folder that has the Visual Studio.exe (devenv.exe) i.e.

cd C:\Program Files (x86)\Microsoft Visual Studio {Version code}\Common7\IDE

For VS 2015 it is

cd C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE


devenv /setup

Reopen visual studio

A similar approach can be used with devenv.exe /Resettings as detailed here.

Reset Visual Studio through file explorer

If the command line doesn’t work then try resetting Visual Studio via the file system. This often works when the command line doesn’t. Try this when Visual Studio is undergoing a profound collapse particularly when it keeps popping up an alert box detailing errors being written here…

C:\Users\{user name}\AppData\Roaming\Microsoft\VisualStudio\{VS version}\ActivityLog.xml

i.e. for Visual Studio 2013


To resolve for Visual Studio 2013

  1. Close VS
  2. Go to C:\Users\tbrown\AppData\Local\Microsoft\VisualStudio\12.0
  3. Rename the folder to C:\Users\tbrown\AppData\Local\Microsoft\VisualStudio\12.0.backup
  4. Reopen VS. The folder C:\Users\tbrown\AppData\Local\Microsoft\VisualStudio\12.0 will be regenerated.

The process is the same for other versions of Visual Studio except the version number at the end will be different i.e C:\Users\tbrown\AppData\Local\Microsoft\VisualStudio\14.0 for VS 2015.

Disable plugins

Leave this one till last because it’s a pain. Go to Tools -> Extensions and plugins. Then disable each plugin you can one by one.

disable plugin box

It’s a pain because even if it is a plugin that causes it, you have a choice of uninstalling and living without it or contacting the vendor. Clearly if you didn’t buy it then the vendor isn’t going to be interested in helping you. I’ve found PostSharp and Resharper the likely culprits here. The Resharper vendor was very helpful. PostSharp weren’t (because we hadn’t bought it!!).

Bizarre Ones

Be careful what you check in

Checking files into source control that you really shouldn’t can cause difficult to diagnose problems. This often happens to me for continuous builds where the user building has fewer privileges than I’m used to. It does happen locally too. The following files shouldn’t be checked in

  • Bin folders
  • Obj folders
  • Autogenerated xml (i.e. documentation generated during build)
  • Packages folder
  • .csproj.user files

If you have checked them in then delete from your disk, remove from source control and rebuild.

Is your file path too long

Windows limits the file path to 260 characters. It could be that you have exceeded this and Visual Studio has started to complain. The awkward thing is that it complains in a very oblique way. The error that you see will be something on the lines of…

“obj\Debug\LongFileName.cs” has an invalid name. The item metadata “%(FullPath)” cannot be applied to the path “obj\Debug\LongFileName.cs “. obj\Debug\\LongFileName.cs           ContainingProject.proj            C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets

So not obvious. Double click the error and it will take you to the Microsoft.Common.CurrentVersions.targets file in the depths of the framework folder. Less than illuminating.

Once you have diagnosed this then the resolution is easy – move your project to a shorter file path. I’ve found this a problem when switching branches which can have longer file paths than the Main branch.

If all else fails

If all else fails uninstall Visual Studio and reinstall. But honestly, I have reached this frustrating point, uninstalled, reinstalled, waited hours and the problem persists. This might not be the cure that you were looking for. Go into a corner and have a good long think before you resort to this one.

So congrats if you have read this far (or commiserations as your Visual Studio install is clearly in a bad way) but hopefully this guide will enable you to have a healthy and happy Visual Studio for years to come.

Useful Links

Good stack overflow explanation on why the 260 character filepath limit exists in windows.

Official advice from Microsoft about bad references.

There is a difference between Clean + Build and ReBuild as detailed here.