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

Simplified Condition for Date/Time aliases #2

Merged
merged 2 commits into from
Nov 21, 2024

Conversation

samtrion
Copy link
Contributor

This means that future versions should also be automatically included.

@samtrion
Copy link
Contributor Author

@SimonCropp What do you thing?

@SimonCropp
Copy link
Owner

isnt NETCoreSdkVersion incorrect? ie someone can use sdk9 and still target netclassic

@samtrion
Copy link
Contributor Author

You are right, it is much more effective if $(TargetFrameworkVersion) is used. If netclassic is used.

@SimonCropp SimonCropp merged commit 69ee4a2 into SimonCropp:main Nov 21, 2024
1 check passed
@SimonCropp
Copy link
Owner

@samtrion so are you actually using this package?

@samtrion
Copy link
Contributor Author

@samtrion so are you actually using this package?

Had experimented with it once, but it didn't fulfil all the requirements / concerns, so no. During the experiment I came across to this pull request, unfortunately without looking at netclassic.

@SimonCropp
Copy link
Owner

fulfil all the requirements / concerns

out of curiosity, how does your approach differ?

@samtrion
Copy link
Contributor Author

I am currently refactoring, so far I had an ‘engineering’ repository as a git submodule. This provided the necessary properties, settings, etc. and the main disadvantage is that I can't integrate it cleanly into existing projects.

Unfortunately, this has increasingly led to complications or errors, as my aim is not only to make specifications, but also to check/validate them accordingly.

I have therefore extended the experiment and am currently starting a deeper phase with a combination of a source only NuGet package and a corresponding analyser. In other words, I'm gradually breaking down my engineering repo and transferring it to these packages. https://github.com/dailydevops/defaults

I do have a clear goal in mind to significantly reduce administration and maintenance effort for new and current projects, but not under all circumstances.

There are a few points in particular that I am focussing on for the experiment, for the start.

  • Default NuGet package information
  • Analyser for NuGet package information
  • Mechanism to allow or disallow references to NuGet packages
  • Shareable .editorconfig, can be partially deactivated via project properties
  • Shareable configurations for banned API analyser, can also be deactivated for project properties

Other points are already on the todo list, but are not part of the ‘experiment’.

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