Skip to content

Conversation

@daxian-dbw
Copy link
Member

@daxian-dbw daxian-dbw commented Mar 22, 2017

Fix #3140

  • FullCLR build is disabled in this change.
  • FullCLR build related functionalities in build.psm1 and AppVeyor.psm1 are disabled. They are not cleaned up from build.psm1 and AppVeyor.psm1 yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts.
  • dnxcore50 and portable-net5+win8 target framework monikers are removed.
  • Dependency on Microsoft.NETCore.Portable.Compatibility is removed. It's not necessary, but it may come back when we work on supporting the portable module. Its necessity can be reviewed at that time.
  • I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by Build powershell core in Visual Studio 2017 #3400

The TypeCatalogParser project is replaced by a MSBuild target to gather the dependency information.
Due to .NET Core SDK issue #1021, our meta-package project Microsoft.PowerShell.SDK starts to generate an empty assembly during the build and that results in an empty assembly Microsoft.PowerShell.SDK.dll appear in publish folder and in .deps.json file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401

/cc: @PowerShell/area-build

"Microsoft.NETCore.App": "1.1.0",
"Microsoft.DotNet.ProjectModel": "1.0.0-rc3-1-003177",
"Microsoft.DotNet.Cli.Utils": "1.0.0-preview3-004056"
"Microsoft.DotNet.ProjectModel": "1.0.0-rc3-1-003177"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the file src/TypeCatalogParser/project.json should be removed.

"frameworks": {
"netcoreapp1.1": {
"imports": [ "dnxcore50", "portable-net45+win8" ],
"buildOptions": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the file src/powershell-unix/project.json should be removed.

"frameworks": {
"netcoreapp1.1": {
"imports": [ "dnxcore50", "portable-net45+win8" ],
"dependencies": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the file test/PSReadLine/project.json should be removed.

"imports": [ "dnxcore50", "portable-net45+win8" ],
"dependencies": {
"xunit": "2.2.0-beta4-build3444",
"xunit": "2.2.0",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the file test/csharp/project.json should be removed.

Copy link
Member Author

@daxian-dbw daxian-dbw Mar 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thank you! These project.json files were revived when I was resolving the conflicts.

@iSazonov iSazonov added the Review - Needed The PR is being reviewed label Mar 23, 2017
Copy link
Contributor

@lzybkr lzybkr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll want to move many of the commonly set properties into a shared .props and include it, but this is fine for a first cut.

@daxian-dbw
Copy link
Member Author

We'll want to move many of the commonly set properties into a shared .props and include it

Track it by #3406

@daxian-dbw
Copy link
Member Author

Talked to @TravisEz13 offline and he has verified that the MSBuild change works on OpenSUSE.
I will merge this PR as Travis is in a meeting and cannot get back to this until late this afternoon.

</PropertyGroup>

<ItemGroup>
<ProjectReference Include="..\Microsoft.PowerShell.Security\Microsoft.PowerShell.Security.csproj" />
Copy link
Collaborator

@iSazonov iSazonov Mar 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not "ProjectReference Include="..\System.Management.Automation\System.Management.Automation.csproj" /" ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Microsoft.PowerShell.Security.csproj has a ProjectReference to System.Management.Automation.csproj, so the dependency is chained together.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ask because all other csproj files contains direct reference on "System.Management.Automation.csproj" and only the file contains indirect reference.

@iSazonov
Copy link
Collaborator

It seems CorePsTypeCatalog.cs don't updated by TypeCatalogGen.exe . Is it well?

@daxian-dbw
Copy link
Member Author

@iSazonov TypeCatalogGen.exe still generates CorePsTypeCatalog.cs. If you mean the content is not changed, then that's expected, because we are still depending on the same set of .NET Core packages.

@iSazonov
Copy link
Collaborator

After Start-PSBuild -restore my CorePsTypeCatalog.cs has still old date (17 jan) and contains links on "4.0.0.1" packages. Is it Ok?

@daxian-dbw
Copy link
Member Author

daxian-dbw commented Mar 24, 2017

You need Start-PSBuild -TypeGen -Publish or Start-PSBuild -Clean -Publish.
-Restore doesn't refresh the CorePsTypeCatalog.cs.

@iSazonov
Copy link
Collaborator

-Clean is key 👍 Thanks!
It seems it is not documented well. 😕
What problems I can catch if my CorePsTypeCatalog.cs is out of date?

@daxian-dbw
Copy link
Member Author

Say we move to .NET Core 2.0 and you are still using CorePsTypeCatalog.cs from .NET Core 1.1, then it may appear that some type resolution would stop working.

@iSazonov
Copy link
Collaborator

Thanks for clarify! It looks that we should add this (-Clean) in our docs for well moving to MSBuild (and .Net Core 2.0): you mentioned in comments that we need only dotnet restore.

@iSazonov iSazonov removed the Review - Needed The PR is being reviewed label Mar 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Move build to csproj/msbuild

6 participants