Major Refactoring and Breaking Changes

[daveaglick]

For anyone watching, I've been thinking about this project a lot lately. Specifically, how I can refactor it so it becomes more maintainable while addressing some of the outstanding issues (like support for new project types and cross platform support). Unfortunately we're battling upstream problems as well - for example: dotnet/roslyn#17968

We'll end up losing some features (like the the Visual Studio Custom Tool), but the hope is that it'll be a more stable foundation to grow on. Right now I'm having a very hard time doing anything to the project because it's just a mess of too many different features that all have to work together.

Here's what I have in mind:

• Remove the Visual Studio extension and custom tool. I know this will impact many users, but .NET is cross platform now and I personally don't want to be in the business of supporting a Visual Studio extension going forward. All the use cases for Scripty can be addressed at build time and if design time evaluation is really needed, Scripty can be run on the command line. If someone in the community wants to take up the Visual Studio extension - go for it!
• Don't manipulate the projects in any way. Output files will get placed on disk next to the parent script, but they won't be added to the project like before. Doing so would be inconsistent anyway given the different project formats and how some now prefer wildcards and globbing patterns to find source files. If they need to be in the project, wildcards/globs can be used in the project file or they can be added after the first generation. Using the MSBuild task will still include generated files in the final compilation as before.
• Remove the support for Roslyn-based project analysis (I.e., the Project.Analysis property). The Roslyn Workspace support for different combinations of project styles, runtimes, platforms, etc. is a mess and doesn't look like it's getting cleaned up any time soon. Instead of spending time trying to hack around those problems, we'll just use MSBuild for now until the situation improves.
• Target netstandard for Scripty.MsBuild (see http://www.natemcmaster.com/blog/2017/07/05/msbuild-task-in-nuget/), Scripty.Core, and Cake.Scripty
• Make two projects (or multitarget) the Scripty CLI to both .NET Framework and .NET Core runtimes

[StingyJack]

I know VS 2017 (especially 15.3) has been bad, but it seems like you really want to distance yourself from it. =P

I guess I dont quite understand how you actually use Scripty to understand your positions on these. As limiting as IVSSingleFileGenerator is, without the VS integration I wouldn't have a use for it.

[daveaglick]

@StingyJack Since writing this I've backed off a little - pretty sure I'll still carry forward the SFG as well as the MSBuild task. That's mostly due to having worked on Buildalyzer and addressing a lot of these issues there. That project will form the core of the next version of Scripty and will make it easier to support the various Scripty tooling libraries since I won't need to worry about the MSBuild/Roslyn mess directly in Scripty.

TL;DR: thanks to recent work in Buildalyzer, I'll be able to keep most of the current Scripty features without sacrificing maintainability as I had previously feared.