When moving between old and new csproj formats, and back again when it doesn’t work, I have several times ended with a project.json error looking like this:

The cause comes from left over files in your obj catalogues.  The file in question seems to named project.assets.json.

Deleting these in all subfolders seems to do the trick.

Run, from the root of your repo:

del project.assets.json /s /q

We’re running a new 2.5 hour seminar on the new Visual Studio 2010 and Team Foundation Server 2010 in Bergen Jan 27th.  See the agenda and invitation at the NNUG site. http://nnug.no/Avdelinger/Bergen/Moter/NNUG-Bergen---Januar-20092/

The seminar runs through a typical development cycle, and using demos demonstrates how Team System 2010 can be utilized to cover the whole lifecycle. The focus is on the new features in 2010, and we will try to cover as much ground as possible.  The seminar is nearly power-point free and very developer friendly !

A new version of the Branching guidance has been released (III), containing very good stuff on how to do branching. It includes labs, sketches and how-to’s.

See http://tfsbranchingguideiii.codeplex.com/

One of my favorites is the diagram poster shown below which I’ve used to explain the different branching strategies, and I find this very useful and easy to explain.  You’ll find it in one of the tabs of the Visio file included in the download package.

The Team System Rangers (http://msdn.microsoft.com/en-us/teamsystem/ee358786.aspx) just released a set of real cool Quick Reference Guidance sheets for the Visual Studio 2010 Team System at Codeplex http://vs2010quickref.codeplex.com/.  These guides collects up so much useful information in just a few slides.  I’ve always loved the branching guidance overview slides, explains so much in so little space.  Here is the same covering many more aspects.  A few….well, few is perhaps not the right word…there are quite a bunch of them, within these areas:

On codeplex the VSTS Rangers have published the Branching Guidance II (yes, a while ago, but still very true).  The basic idea there is the separation between 3 major branches,  the Main (or trunk), the Development and the Release branch.  One can elaborate on these and use multiple Development branches, and also a tree of release branches, but the basic principle can be summed up with these three.

Visual Studio 2010 (beta 2) can be connected to an existing TFS 2008 Server.  Much of the new great stuff is then not available, quite naturally.  But I was quite positively surprised that some stuff I had not expected to work in fact did.  Which of course means it’s client stuff more than server stuff. Anyway, here comes:

History across branches:  You can now see the history of a versioned item even it started it’s life in another branch, and even if you are connected to a TFS 2008 server.

In June we ran a free 2,5 hour seminar at Microsoft on the Team System 2010.  It went rather well, so it's being set up again, on September 15th.  It's being done as a practical demo case, we've "invented" a problem, and uses the 2010 to solve the problem. In the process of doing that, we're going through the Architect parts, the work items, the build system, coding, branching, code reviews with the static code analysis, testing with the new Test Edition ("Camano") and more.   We've done it nearly power point free :-).

In Visual Studio the settings for static analysis is done on the project property page, a tab called Code Analysis. You can set which code analysis rules you want to be active.  The default in Visual Studio 2008 is to use all.   If you run with this default setting you will generate a lot of "noise", since there are a large set of rules.  You need to create a set containing the rules you and your team find are suitable for your organization and project.  This set you have to apply to every C# project in your solution.  In Visual Studio 2008 there is no easy way to do this.  At Osiris we made an Addin to Visual Studio to ease this.  We defined the set in a separate file, and used the Addin to apply that to all projects in a solution.

We have run 10 seminars with myself, Mikael Nitell and Jakob Ehn on TFS 2008 during the last two years. These seminars were made from the point of our company's experience with the TFS system.  We debated different aspects of it, and showed people how we had chosen to solve the different issues that arose.  These seminars took in the range of 4 hours, and we've had around 700 people all in all participating in these seminars, with very favorable feedback. 

There has always been a controversy between modeling and coding.  All from the point where models are to be turned into code automatically, through the state where models are written and then forgotten after coding has started, to the point where one generates models from the code.

To me, code and model is representations of the same thing - the problem to be solved, or the solution to the problem.  And when the solution matches the problem, which sometimes happens, all is well.

All these three terms are used to describe the behavior of an application.  They come from different process methodologies, and have different meanings, characteristics and are intended to be used differently.

Larry Guger also discuss these aspects and several others in his blog entries http://continuouslyintegrating.blogspot.com/2009/07/use-cases-and-visual-studio-2010-part-1.html and http://continuouslyintegrating.blogspot.com/2009/07/beginning-use-cases-identifying-actors.html.  

The Use Case is the term used in UML and in the different Unified Process based methodologies.  See http://en.wikipedia.org/wiki/Use_case for a good overall description.  A use case is often looked upon as a more formal way of describing behavior, and which has to be accompanied by a detailed description following certain rules.  However, a Use case can in fact be as light weight or as formal as one wants it to be.  I find that this depends more on the process methodology one uses more than characteristics of the use case itself.

When I started blogging I made a decision to concentrate on technical stuff.  I would not write about personal things, not about what happened in my everyday life, not about my social life, not about personal trivia, but just keep it technical - write about software and software technology.  And keeping my personal life and my technical life separated seemed like a good idea, and shouldn't pose any problem what so ever. 

I was informed April 1st that I had received the MVP Award for Team System. It first appeared on the blogsite of Rune Grothaug, and later the same day a mail dropped into my Inbox from Microsoft.  I knew about the nomination, but when it materialized I still got very happy and excited about it.  It’s great to join such a group of talented people,  but it also makes me feel the pressure to do even more for and within the community.  I have always enjoyed sharing knowledge with other people, but this has normally happened in small groups. I’ve not been the typical writer or blogger, although I enjoy writing and communicating. Either I’m out of time, or I don’t feel the stuff is well enough prepared, or I’m just holding a bit back. The shy guy, you know….  

Jakob got out a cool checkin policy after a question on the microsoft forums about this. The policy ensures that you have run a code coverage, and that the coverage percentage is above a certain set limit.  See Jakob's blog for a description http://geekswithblogs.net/jakob/archive/2009/02/23/writing-a-code-coverage-checkin-policy.aspx

The code is available on codeplex, see here http://www.codeplex.com/TFSCCCheckinPolicy.

A build set is a set of builds running on the same solution or set of solutions, catering for different aspects of the Continuous Integration process.  Why a set of builds ?  Because one size doesn't fit all.  Something you want to run quickly and others you want to cover a lot of stuff.  This can be divided into a set of aspects.

The aspects can be divided into three major parts:

At the moment there are five different popular process templates, three from Microsoft official, one on Codeplex (by some Microsoft guys afaik), and one from Conchango.  The fields defined in the workitemtypes found in these templates belongs to a set of namespaces.  The System namespace is a predefined Microsoft namespace, with special behavior.  The other ones are in reality free text.  However, since some effort has been placed on defining these namespaces, and some of these fields are used in several reports, in mappings to Microsoft Project etc., it is wise to adhere to these definitions. It will at least reduce the work you have to do if you're modifying them, or defining your own types.  It is also wise to keep the fields named as equally as possible between types, and even processes, because it also simplifies querying across types. See http://teamfoundation.blogspot.com/2008/05/work-item-customization-tidbits-part-1.html for a great tutorial on how-to-do-it.

I like Code Metrics.  They give a certain "objective" evaluation of a piece of code.  You can use it for yourself just to make it pinpoint potential trouble areas, or just some code where you were a bit sloppy - happens from time to time......  And when you're going to do a peer review, it's much better to point to some numbers instead of  the "This code sucks....."-thing.   So when it finally arrived inside Visual Studio I was delighted. 

I did an article on Subsystem branching (http://geekswithblogs.net/terje/archive/2008/11/02/handling-subsystem-branching.aspx) as a result of a post on the Microsoft forums regarding this.

Further, at the PDC 2008 conference now, Grant Holliday made me aware of the TFS Dependency Replicator, which also is a way to solve the problem. It corresponds to the solution I named Solution 3B, however, it's not using the branch/merge facilities, so the TFS itself is not "aware" of the file copied. Anyway, a great tool !

I'm just soooo slow.  I must be the last geek to get a blog up and running. Anyway, being last is better than never.

Where to find me:

I'm often found at the Microsoft forums, Forums.Microsoft.com/MSDN mostly under Visual Studio Team System, but occasionally also under any of the more programming forums, like Winform, WPF, ASP.Net., C# or SQL.  My nickname there is OsirisTerje.

I got an audio technology site also, see http://home.online.no/~tsandstr/AudioStartsHere.htm, which contains information from my former life.

Setting up Visual Studio Code

C# extension

Add the standard C# extension

Solution extension

Add the solution extension

This goes together with organizing your code with a parent folder, called solution root, and then having each C# project in a corresponding subfolder. Add these projects to your solution using the solution extension.

Debugger

The C# debugger comes with the standard C# extension

Set up the debugger as shown in this post

If debugger won’t start, and saying things like Omnisharp server not running, then run the command (from the command palette) Omniserver restart and then Generate assets for debug.

Starting up with C# and .Net Core

Get the tools

.Net core

Ensure you have the .net core sdk installed.

Download and install it from here

The run the following command to ensure you got it all right:

dotnet

(then)

dotnet --list-sdks

The first should just show you itself. The second lists the sdks you have installed with their version numbers.

IDEs

You should at least have Visual Studio Code

Start it up and from the Extensions icon (on the left side, 5th down probably) add the following extensions: