- Project dependencies are always built into their specific folders and the main project is the only one that uses the output path and intermediate output path variable.
- Publish respects the output path for publish only, not compile as part of publish. This means that publishing multiple runtimes will stomp on each other. So don't do that. We can throw if you specify and output location and you haven't specified a specific combination of RID and framework. Alternatively it should probably just pick the first TFM/RID pair from the lock file. This is similar to how `dotnet run` works.
- Cleaned up the incremental build output formatting
- Use a single stream (output stream) since interleaving them was causing formatting issues (like losing random characters in the middle of outputting things).
- Didn't change how pack works, it still preserves the output structure when passing `--output`, this one is worth discussing. We could leave the build output inplace and only move the package to the output location. That's more consistent with how everything else works and can be a follow up PR.
With this change, any referenced analyzer project will be parsed by the
project system and the assemblies will be passed down to the compiler.
By default, the analyzer language is considered to be "cs". If another
language is used, the "languageID" option should be specified inside the
"analyzerOptions" section of the project.json file.
Resolves#83
- There are 2 major cases to auto reference facades:
1. When using a netstandard/dotnet* based package on a platform where the System.* packages don't provide any compilation assemblies.
2. When referencing a PCL where no dependencies were specified in the nuspec.
- For 1, we handle it by replacing package references with reference assemblies if possible. For 2. We turn assembly references of PCL assemblies into package dependencies.
This should cover the 90% case where people had to manually reference facades anytime they wanted to use a PCL on Net4.x.
TODO: P2P PCL references
#164
Renaming variables according to code review comments. Adding the folder logic to the builder tests. Creating a separate compilation folder during the build.
Changing the build scripts to copy files over from debug\dnxcore and to check for the folders existence before trying that.
Making the build command aware of the subfolders and making E2E tests aware of subfolders.
Fixing compiler tests to look for the xml in the right plae taking into consideration the configuration and tfm.
Modifying publish tests to not take into consideration the runtime. This is a temporary change. will bring it back once the commands all understand rid.
Making the packaging step work by placing binaries where dotnet pack expects.
- Fixed a bunch of dependencies that was causing dotnet restore to fail on the CLI
- Added imports to `project.json` so that `dotnet-restore` works
- Fixed a bunch of dependency issues in different projects
- Ironically, running `dotnet restore` on the dotnet-restore project still fails (will fix in another commit). Looks like it might be a nuget issue
1. Rebase on new LibraryExporter
2. Update dependency name to "fx/<name>" for reference assembly
3. Update framework friendly name
4. Fix dependency message regression
5. Update tests
CentOS tests were blocked due to issue https://github.com/dotnet/corefx/issues/5066.
It has been fixed with the latest NetStandardLibrary, hence upgrading from 1.0.0-rc2-23616 to 1.0.0-rc2-23704.
With this fix the native shims are correctly restored by dnx for RID centos.7-x64.
- Removed unused message types
- Removed intermediate ProjectInfo and ProjectState types
- Renamed Snapshot to ProjectSnapshot and ProjectSnapshot to ProjectContextSnapshot
- Exposed Project on ProjectContextCollection
- Removed AllDiagnostics message since it won't be used
- Renamed ProjectContextManager to ProjectManager
- Create project context snapshot in one pass
- Create project contexts lookup inline
- Consistent naming of payloads
I had to patch up a redhat dnx package which supports NETStandard.Library package. It is currently uploaded to dotnet-cli blob storage. This hack will no longer be required when we move to xplat nuget to do 'dotnet restore'. Apart from this there are three issues that are tracked for centos.
- compile-native not yet supported - https://github.com/dotnet/cli/issues/453
- dnu restore crashes intermittently on centos. I need to investigate this a little bit more and file issues on dnx or coreclr. This will make our CI builds very flaky.
- Dotnet restore does not restore native shims when using “centos.7-x64” - https://github.com/dotnet/corefx/issues/5066
