DNX Compatibility

[smudge202]

Having accidentally hijacked #33, I'll move relevant information to this issue so that the 3 separate issues currently being discussed in aforementioned issue can become less confused.

DNX is currently in RC1, and according to the most recent ASP.Net Standup will actually diverge from the planned roadmap to a Core CLI model. (See video for more details).

DNX is in layman's a host that can run on many platforms with many runtimes. The replacement Core CLI work will likely be very similar, at least from the point of view of BenchmarkDotNet.

Currently, if trying to use BenchmarkDotNet within a dnx hosted project, you will receive the following error:

This is caused by this line of code which tries to retrieve the entry assembly's location. Assembly locations do not make sense in the context of DNX and I think will still not make sense when it's successor arrives.

Therefore, we need to examine the overall process that relies upon these assembly locations to try and find a mechanism that will allow for dnx projects to work.

Note: This is not the same as CoreCLR Compatibility which I'll raise as a separate issue.

[mattwarren]

This is caused by this line of code which tries to retrieve the entry assembly's location. Assembly locations do not make sense in the context of DNX and I think will still not make sense when it's successor arrives.

I guess you actually meant [this line of code]?(https://github.com/PerfDotNet/BenchmarkDotNet/blob/master/BenchmarkDotNet/Toolchain/Classic/BenchmarkClassicGenerator.cs#L155) (one line below where you linked to)

Either way, I assume that we are also going to have problems with this code I introduced in e5538b9 to solve #42?

[smudge202]

Yes and yes. My mistake; bad copy pasting.

In my local WIP I actually moved both the code you mentioned there and line 155 to a helper method along the lines of GetFileInfoForAssemblyContaining(Type type). Totally forgot about it when raising the issue.

[adamsitnik]

Few hours ago I started working on that (link) and I got stuck at the same place. Tommorow I will try to implement IBenchmarkGenerator interface with relying on dnu instead of msbuild. I have no idea if I am going to succeed but I am going to try :)

[AndreyAkinshin]

@adamsitnik, cool!

[AndreyAkinshin]

@adamsitnik, yesterday I released new v0.8.2. I recommend you to merge it into your branch.

[adamsitnik]

@AndreyAkinshin thanks! you have saved me a lot of time!

[mattwarren]

@adamsitnik thanks for doing this!

BTW, I like the way you are structuring the process, it's pretty easy to follow your commits and get a good idea of what has to be done to port to DNX/CoreClr/.NET Core 1.0 (or whatever the name of it is!!)

[adamsitnik]

@AndreyAkinshin @mattwarren I made some progress today. I think that I have found the right package to use: Microsoft.Dnx.Compilation. It allows to compile and supports both DNX and Core. I did some research on that and did some proof of concept.

I must admit that the code is really plugin/extension friendly! Great use of interfaces!

However right now I get some compilation errors, but all of these seems to have single cause. When I get rid of this then I will try to implement actual benchmark execution.

[AndreyAkinshin]

I must admit that the code is really plugin/extension friendly! Great use of interfaces!

Excellent! You are one of the first users of our plugin system, so, feel free to make improvements in case of troubles. Main goal of the generator/builder/executor system is Dnx/CoreCLR support.

[mattwarren]

@adamsitnik I just came across these docs Making your libraries compatible with .NET Core and other .NET Platforms and found out about the .NET Portability Analyzer (you can also get it in Visual Studio via Tools -> Extensions and Updates).

I ran it on the current BenchmarkDotNet code and got this report PortabilityAnalysis.zip (zip of a .html file), maybe it's useful for what you're doing.

Although I guess that you've already figured out the areas where we're not compatible!!

[adamsitnik]

@mattwarren Thanks for the report, it was usefull!

The biggest problem is moving from msbuild to dnx. The way of referencing, buliding and executing code has changed ;/ But we get cross platfrom .NET for that!

My plan:

1. DNX451 a) add package restore by either calling dnu restore or Nuget3 package restore. Nuget 3 will replace dnu restore in the future b) replace msbuild compilation with dnu build or direct call to Microsoft.Dnx.Compilation (core version of Roslyn). I got dnu build running, but the alternative version fails. I guess that when MS ships new nuget version it should work c) replace direct Process.Start(Program.exe) with some way of doing dnx run. Did this manually and worked, will resarch soon for possible solutions. d) test, test & test: from VS, from xunit.runner and as standalone e) PR
2. DOTNETCORE a) adopt to Reflection and other API changes. Should be easy b) if 1a & 1b are done in xplat way then just test

Other interesting thing is that msbuild is going to be cross platform too! But when? Code

[adamsitnik]

I just got it working for VS/xUnit. By it I mean compiling and running with DNX.

I still have a lot of things to do but I am really optimistic now.

[AndreyAkinshin]

@adamsitnik, sounds great!

[mattwarren]

@adamsitnik congrats!

[adamsitnik]

@AndreyAkinshin @mattwarren Small update: I just got all tests green and it works from VS/xUnit and for standalone applications as well. I will try to describe whole process, limitations and testing and PR tomorrow or on Sunday. I would like to make it before next merge ;p

[mattwarren]

@adamsitnik great, look forward to it.

[AndreyAkinshin]

@adamsitnik sounds good.

[khellang]

What's the status on this?

[adamsitnik]

@khellang Implemented, waiting for approval