- Building
- Debugging
- Running Tests
- [Development] (#development)
- [Chat room] (#chat-room)
- [F#] (#f-sharp)
Required:
- Visual Studio 2015 Update 1
- ASP.NET 5 RC I am not sure about this, but it installs dnx toolchain and DNX/CORE projects templates.
- dotnet cli toolchain
- Internet connection to download all packages
If your build fails because some packages are not available, let say F#, then just disable these project and hope for nuget server to work later on ;)
- To debug "dnx" you simply press F5 in Visual Studio.
- To debug "classic" version you need to configure VS to start executable on debugging, for our purposes I have already done this for Samples project
- To run "classic" tests build the solution and run runClassicTests.cmd in the root directory. I had to make it this way because currently VS/xUnit does not support running dnx and non-dnx tests in single way.
- To run "dnx" tests you just need to open Test Explorer in Visual Studio and rebuild the solution.
Remember to do both before pulling a PR or publishing new version
Please, use the develop branch for developing. The master branch should correspond the latest NuGet package of the library.
.csproj and package.config files have been replaced with .xproj and project.json files. project.json automatically references all .cs files so you don’t have to update it with every new class/interface/enum added (number of git conflicts has just dropped). It also has some side efects. For example if you create some subfolder in any of the folders that contain project.json file and put some .cs files there, then these files are going to be compiled as part of parent project by default. This is why in DNX we don't put autogenerated folders as subfolders of Samples/IntegrationTests folders. If you want to exclude some files from compilation then you can simply put rule for that in project.json file. Sample:
"compileExclude": "**/Program.cs".The other side effect is that xproj displays all files by default:
But if you want to include some files as resources, you have to do this in explicit way:
"resource": [ "Templates/*.txt", "Templates/*.R", "Templates/*.json" ]Project.json allows us to target multiple frameworks with one file and manage all dependencies in single place. Simplicity over complexity!
"frameworks": {
"net40": {
"compilationOptions": {
"define": [ "CLASSIC" ]
},
"frameworkAssemblies": {
"Microsoft.Build": "4.0.0.0",
"Microsoft.Build.Framework": "4.0.0.0",
"Microsoft.Build.Utilities.v4.0": "4.0.0.0",
"System.Management": "4.0.0.0"
}
},
"dnx451": {
"compilationOptions": {
"define": [ "DNX" ]
},
"frameworkAssemblies": {
"System": "4.0.0.0",
"System.Runtime": "4.0.10.0",
"System.Management": "4.0.0.0",
"System.Reflection": "4.0.0.0"
}
}
}Project.json.lock tells the compiler exactly where to look for our dependencies. You can produce it with „dnu dotnet restore”. Sometimes VS will do this for you (currently VS is still using dnu), sometimes you will have to do this on your own. Dnu is just an alias for a part of Dnx.
There are at least 3 types of dependencies. Project, package and build. There is no need to speficy it in explicit way unless it is build. Build is for compilation helpers like the one we use to compile our F# sources for DNX. If you want to reference project, then you can just type project, otherwise just forget about it. Sample:
"dependencies": {
"BenchmarkDotNet": {
"target": "project",
"version": "1.0.0-*"
}
}When you want to add some dependency then you just add in in the right place in project.json. It depends on which platforms the library that you would like use supports.
- If it supports all frameworks then you just need to move the dependencies to common dependencies (same level as frameworks, same thing applies to frameworkAssemblies).
"frameworks": {
"net40": { },
"dnx451": { }
},
"dependencies": {
"someCommonDependency": "it's version"
}- If there are few different packages/version then you need to specify both dependencies in explicit way:
"frameworks": {
"net40": {
"dependencies": {
"someCommonDependency": "exact version that supports net40"
}
},
"dnx451": {
"dependencies": {
"someCommonDependency": "exact version that supports dnx451"
}
}
}- If the desired package does not support all frameworks, then you add it as dependency to specific framework, but in code you use ugly #if #endif to exclude it for other compilation targets. We define #CLASSIC, #DNX and soon #CORE. In other OSS projects you can meet more complex names like #NET40, #NET451, #DNX451 or #DNXCORE50.
#if CLASSIC
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
namespace BenchmarkDotNet.Loggers
{
internal class MsBuildConsoleLogger : Logger
{
private ILogger Logger { get; set; }
public MsBuildConsoleLogger(ILogger logger)
{
Logger = logger;
}
public override void Initialize(IEventSource eventSource)
{
// By default, just show errors not warnings
if (eventSource != null)
eventSource.ErrorRaised += OnEventSourceErrorRaised;
}
private void OnEventSourceErrorRaised(object sender, BuildErrorEventArgs e) =>
Logger.WriteLineError("// {0}({1},{2}): error {3}: {4}", e.File, e.LineNumber, e.ColumnNumber, e.Code, e.Message);
}
}
#endif- If it is not a package, but dll/exe file then you need to create wrap for it. You can do this for VS, but currently it will not work with dotnet cli, since it is going to produce wrong path. This is why I recommend to do this manually. You just need to create new folder in solution's root, then put project.json file there and add the folder to global.json file. Sample wrap file:
{
"version": "1.0.0-*",
"frameworks": {
"net40": {
"bin": {
"assembly": "../CLRMD/Dia2Lib.dll"
}
}
}
}Currently due to dnx/dotnet cli limitations we do not have working F# samples. It used to work when we used only dnx, but with move to dotnet cli it is currently impossible. Why? Because VS is still using dnx, but when it moves to cli then it should be simple to switch.
