Change the way of generating new project file

[adamsitnik]

As of today, we generate the .csproj file by filling this text template.

The main disadvantage of this approach is that if there are any custom MSBuild settings in the project with a benchmark that we are not aware of, we sometimes fail to build the project and hence fail to run the benchmarks.

We used to follow a similar approach for generating the app.config files, but at some point in time we changed the approach to "rewrite everything from the source file unless it's on our list of settings". The code can be found here

I propose that we switch to a similar approach with the .csproj file:

• copy the source project file
• update all relative paths
• replace the settings we know (TFM, optimizations enabled, project name etc)
• add a reference to the source project

This should fix:

• Forward msbuild properties to project reference Forward msbuild properties to project reference #1377
• This type has been forwarded to assembly [Paket] This type has been forwarded to assembly #1392
• Not able to run a project referencing to private nuget package Not able to run a project referencing to private nuget package #1358
• Can I run a CMD command during the toolchain lifecycle? Can I run a CMD command during the toolchain lifecycle? #1345
• Enable including references in autogenerated csproject Enable including references in autogenerated csproject #1197

and a few more issues

[adamsitnik]

@WojciechNagorski if you are still looking for some task then most probably this one would have the biggest impact (it's going to solve at least 10+ bugs)

[WojciechNagorski]

@adamsitnik Yes, I would like to solve this task. I will find time next week.

[adamsitnik]

Yes, I would like to solve this task. I will find time next week.

Awesome! I've assigned you to the task.

[WojciechNagorski]

Update: I've thought for 2 weeks and I think that I invented the final solution for all cases.

[adamsitnik]

@WojciechNagorski awesome :D