Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dnu parity #64

Closed
davidfowl opened this issue Oct 17, 2015 · 10 comments

Comments

Projects
None yet
6 participants
@davidfowl
Copy link
Collaborator

commented Oct 17, 2015

In the next 2 weeks, we'd like to be able to change the ASP.NET build infrastructure to use dotnet cli. To do that we need to make sure we have parity for most of the commands. This is an issue to track the bare minimum required for us to switch over:

  • - Running prebuild, postbuild events in project.json
  • - Running prepublish, postpublish events in project.json
  • - Compile module support in the compiler (TBD)
  • - Support for resources #68
    • - Embedded resources
    • - Resx files
  • - Support for all compilation options defined in project.json
  • - Support for all 3 OSes (linux, osx, windows)
  • - .NET Framework support (as a compilation output)
    • - Support for compiling with mono reference assemblies - This may or may not be a big issue. (this is enabled right now via an env variable). There's still work needed here. See dotnet/corefx#3934
  • - Publish to support copying content files to the output folder (aka msbuild's copy to output) - see #61
  • - Showing dependency diagnostics on the command line
  • - Disable binding redirect warnings #47
  • - Add support for generating binding redirects for .NET Framework #397
  • - Globbing support for dotnet compile
  • - Support generating dll metadata based on project.json metadata - #398
  • - Satellite resource assembly generation (today we use roslyn but maybe we need a resgen port?) #403

Commands

  • - dotnet run see #59
  • - dotnet pack (dotnet compile -> nuget pack)
    • Generate symbol packages #495
  • - dotnet test This one is a little fuzzy. The DNX handles testing very differently but we can do something here.

Engineering

  • - Performance needs to be as good as dnu build - Was using in roslyn in memory, so saw all the benefits of caching metadata refs and syntax trees (for cross compile)
@davidfowl

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 17, 2015

/cc @jaredpar some of the compiler options expressed might not be in csc. We were using them using the compiler API in dnu but we need to expose them from csc for parity.

@davidfowl

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 17, 2015

/cc @jaredpar one advantage we had doing compilation in memory was that we were able to only add metadata attributes if the assembly didn't already apply them. Checking was super easy. Shelling to csc makes it much harder to do.

@jaredpar

This comment has been minimized.

Copy link
Member

commented Oct 17, 2015

@davidfowl is this an item we can fix by getting generators into the compiler used by 'dotnet compile' faster?

@davidfowl

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 18, 2015

Yes 👍

@richlander

This comment has been minimized.

Copy link
Member

commented Oct 28, 2015

@blackdwarf are you following this? To get us towards Fowler parity. Oh damn, wrote that wrong, I meant dnu parity. Oops. Total mistake.

/cc @davidfowl

@blackdwarf

This comment has been minimized.

Copy link
Contributor

commented Oct 28, 2015

@davidfowl what is the "test" command? Can you go into more details there?

@davidfowl

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 28, 2015

DNX (the runtime) has a concept of commands, they are basically a short hand for running an entrypoint with some arguments:

https://github.com/aspnet/dnx/blob/dev/test/Microsoft.Dnx.Tooling.Tests/project.json#L12

For example ran the xunit runner when ever you ran dnx test in this folder:

Here's the dnx xunit runner:

https://github.com/xunit/dnx.xunit#usage

We basically had an expected protocol that test runners would implement so that we could make command line testing and VS testing work through the same command.

@davidfowl

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 2, 2015

@blackdwarf I have a design in mind for dotnet test.

@davidfowl davidfowl added this to the RC2-Feb milestone Dec 3, 2015

@TheRealPiotrP

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2015

@davidfowl, can you update this list and make sure we have issues tracking remaining work?

@andschwa

This comment has been minimized.

Copy link
Member

commented Dec 8, 2015

@davidfowl is there any preview I can use for dotnet-test? We've had to switch from DNX to dotnet-cli, but it means we can no longer run our xUnit tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.