Replies: 1 comment
-
|
.NET Framework is still supported through .NET Standard. It's just not a first-class target framework anymore. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I was working through debugging an issue in one of my code bases earlier today and noticed that CliWrap had been updated. It's been awhile. So I gave it a look. And I noticed the dropping of support for Framework that happened awhile ago. I also believe since it has a netstandard build it'll "PROBABLY" still work.
But I did want to raise the issue somewhere.
This project I'm working on is itself an SDK for a build system for what is essentially a custom language type. In our custom MSBuild tasks, we execute a number of external tools. And I've used CliWrap to do that up until now, since it has made it quite a bit easier to trap output and such.
However, MSBuild, in the most widely used IDE for .NET development (Visual Studio), always runs inside .NET Framework. Which means all custom tasks run inside .NET Framework. Which means in my caes CliWrap runs inside .NET Framework. This is unlikely to change any time soon. Same applies to extension development for Visual Studio.
It is likely true that some day something will end up broke that requires me to remove CliWrap.
But, I know you made a post about how "old" .NET Framework is.
Sure.
Except it's still a required component of huge numbers of Windows software (Visual Studio ranks up there). And usage of the tool from those domains would require that downstream libraries support it.
Just FYI.
Beta Was this translation helpful? Give feedback.
All reactions