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

Update Nuspecs Net folder version #9250

Merged
merged 1 commit into from
Nov 28, 2018
Merged

Update Nuspecs Net folder version #9250

merged 1 commit into from
Nov 28, 2018

Conversation

QilongTang
Copy link
Contributor

Please Note:

  1. Before submitting the PR, please review How to Contribute to Dynamo
  2. Dynamo Team will meet 1x a month to review PRs found on Github (Issues will be handled separately)
  3. PRs will be reviewed from oldest to newest
  4. If a reviewed PR requires changes by the owner, the owner of the PR has 30 days to respond. If the PR has seen no activity by the next session, it will be either closed by the team or depending on its utility will be taken over by someone on the team
  5. PRs should use either Dynamo's default PR template or one of these other template options in order to be considered for review.
  6. PRs that do not have one of the Dynamo PR templates completely filled out with all declarations satisfied will not be reviewed by the Dynamo team.
  7. PRs made to the DynamoRevit repo will need to be cherry-picked into all the DynamoRevit Release branches that Dynamo supports. Contributors will be responsible for cherry-picking their reviewed commits to the other branches after a LGTM label is added to the PR.

Purpose

DYN-947
Update DynamoCore Nugets to bundle net 47

Since all projects under Dynamo.All.sln is converted to build with .Net 4.7, updating our nuspec defination to put them under correct folder Net47

Inside Dynamo.all.sln, we do not need to update project reference unless we update Greg soon to build on .Net 4.7.

I will check if I can use any public repo in DynamoDS org to validate this work, but even that will happen after this PR merged.

Declarations

Check these if you believe they are true

  • The code base is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning, and are documented in the API Changes document.

Reviewers

@alfarok @ColinDayOrg @aparajit-pratap

FYIs

@mjkkirschner

@ColinDayOrg
Copy link
Contributor

LGTM

@mjkkirschner
Copy link
Member

@QilongTang does revit and samples build after this change - I guess we need to update those repos?

@QilongTang
Copy link
Contributor Author

@mjkkirschner Sure, but DynamoRevit will not break until we publish the new nugets publicly. So we can actually safely merge this PR, make the changes in DynamoRevit repo, copy the locally built nuget over and make sure DynamoRevit builds and publish in the end.

@aparajit-pratap
Copy link
Contributor

@QilongTang is there a way to autogenerate the .nuspec files while building the projects with the right project configurations?

@QilongTang
Copy link
Contributor Author

QilongTang commented Nov 15, 2018

@aparajit-pratap Good point! It is actually possible, but harder to maintain in our case because:

  1. We have several nuget which is not based on Dynamo csproj, e.g. ZeroTouchLibrary. So the process for these nuget is still manual
  2. Even we do generate the nuspec from some of the csproj, lots of setup needs to happen like aligning the nuget package name with the csproj assembly name, e.g. DynamoVisualProgramming.Core vs DynamoCore. Only after all the setup is aligned, nuspec can be created and we still need to parse XML to fill whatever info left.

So these two reasons making the automation less appealing to us in exchange of the benefit that dependencies appear automatically in the nuspec. I think this approach makes better sense if we have less nugets managing and assuming they all come from a corresponding csproj file.

@alfarok alfarok added the LGTM Looks good to me label Nov 16, 2018
@mjkkirschner
Copy link
Member

I guess another consideration here is do we want to configure dynamos core build to produce both .net 45 and 47 targets.

@QilongTang
Copy link
Contributor Author

QilongTang commented Nov 20, 2018

@mjkkirschner I think it would be valuable to do so which require us to have two sln file and build both in the Dynamo CI/CD. Inside the group, we will take this as a requirement for the new DynamoCore CI/CD pipeline. Do you think we need to make it happen by Dynamo 2.1 release? If that's the case, we need to work with BRE team right now, otherwise gonna miss the boat. Or you are fine doing it at next release using hopefully the "new Pipeline"

@mjkkirschner
Copy link
Member

fine with after 2.1

@QilongTang
Copy link
Contributor Author

QilongTang commented Nov 28, 2018

Looking at the changes more carefully, since this change is applied to DynamoRuntime and SignDynamo nugets internally, we may need to update our build script and Revit CI/CD as well. I am going to at least merge it and publish the nuget using Jenkins tonight.

Follow up PR: DynamoDS/DynamoRevit#2272
Another PR in DynamoSamples constructing

@QilongTang QilongTang merged commit 2616e36 into master Nov 28, 2018
@QilongTang QilongTang deleted the UpdateNuspecsForNet47 branch November 28, 2018 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LGTM Looks good to me
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants