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

feat: Add target sdk for template #1152

Merged
merged 3 commits into from
Jul 9, 2023
Merged

feat: Add target sdk for template #1152

merged 3 commits into from
Jul 9, 2023

Conversation

linkdotnet
Copy link
Sponsor Collaborator

This Pull Request does the following additions / changes:

  • Added the target SDK as optional parameter when creating the bUnit project
    • It currently targets net6.0 as this is the current LTS. I thought about scripting this away, but it seems way easier to bump our default every 2 years and remove obsolete versions and set the default to the current LTS
  • I updated the dependencies to the latest state
  • Fixed an issue with h2/h3 in the changelog.md

This tackles partially #1093

@linkdotnet linkdotnet requested a review from egil July 9, 2023 13:21
@egil
Copy link
Member

egil commented Jul 9, 2023

Nice. I do think the right choice is to make the current latest non-preview the default.

@linkdotnet
Copy link
Sponsor Collaborator Author

Nice. I do think the right choice is to make the current latest non-preview the default.

Said and done

@linkdotnet
Copy link
Sponsor Collaborator Author

linkdotnet commented Jul 9, 2023

After playing around a bit - I have to say I am not in favor of having the 3rd party packages updated automatically when someone calls dotnet new bunit for the following reasons:

  1. If you don't have internet, we have to define a fallback anyway
  2. I, personally, don't like when we do stuff in the post-install script. That remembers me of the npm fiasco. In any case: The user has to trust us even more. Especially, because our post-install scripts might open up a side-channel for other attacks.

@egil
Copy link
Member

egil commented Jul 9, 2023

Ideally, our template would actually do a dotnet new xunit/nunit/mstest followed by a dotnet package add bunit and then a script that make the necessary adjustments to the csproj file. I do not know if that is possible to create.

This way, we do not have to keep our xunit/nunit/mstest templates in sync with the official ones.

The alternative is to basically create our template dynamically at build by creating xunit/nunit/mstest projects, make adjustments, and package all things up into a template.

@linkdotnet
Copy link
Sponsor Collaborator Author

Yes it is possible:
https://github.com/dotnet/templating/wiki/Post-Action-Registry

We could also add the newly created project to the parent solution

@egil
Copy link
Member

egil commented Jul 9, 2023

We could also add the newly created project to the parent solution

That seems risky, e.g. some repositories also have multiple solution files. Probably leave that to the end user and just do the same as the other test frameworks templates do in that regard.

@egil
Copy link
Member

egil commented Jul 9, 2023

Yes it is possible: https://github.com/dotnet/templating/wiki/Post-Action-Registry

We can look at that in another PR.

@linkdotnet
Copy link
Sponsor Collaborator Author

That sounds like a plan - at least from my point of view the PR makes the situation to some extent "better".

@linkdotnet linkdotnet merged commit 70c1338 into main Jul 9, 2023
4 checks passed
@linkdotnet linkdotnet deleted the feature-1093 branch July 9, 2023 16:58
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.

2 participants