Open HamedFathi opened 8 years ago
At this time, Scripty is not compatible with .NET Core as a runtime.
The NuGet package (which contains an MsBuild task) may work for .NET Core applications provided you build on a Windows platform, but I haven't tested it.
The Scripty Visual Studio extension will not work for .NET Core applications because Visual Studio does not support single file generators for that project type yet.
I plan to take a closer look at Scripty with regard to .NET Core once the .NET Core tooling hits 1.0 (it's currently in preview).
With the impending RTM of VS2017 and stabilization of .NET Core, is there any appetite for re-opening this issue?
@MichaelFStarke There's definitely interest in moving to Core. As you said, the tooling is now nearly 1.0 and MSBuild is gaining Core support as well.
As with all of the Scripty issues, the biggest impediment at the moment is my availability. Not sure when I'll have a large block of time to handle this and other improvements, but I'll certainly tackle it eventually.
For now, should probably open the issue back up.
I would like to bring some extra information to this discussion.
I have spent some time experimenting with Scripty with the latest version of Visual Studio 2017 and it turns out that there is some pretty deep incompatibilities with .NET Core and the new csproj format.
The Scripty build target will fail with the following exception when trying to build a solution that contains a .NET Core project, even if Scripty's build target was installed on a .NET 4.6 project.
Scripty.MsBuild.targets(27,5): error : Microsoft.Build.Exceptions.InvalidProjectFileException: The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.
Scripty.MsBuild.targets(27,5): error : at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
Scripty.MsBuild.targets(27,5): error : at Microsoft.Build.Construction.ProjectParser.Parse()
Scripty.MsBuild.targets(27,5): error : at Microsoft.Build.Construction.ProjectParser.Parse(XmlDocumentWithLocation document, ProjectRootElement projectRootElement)
Scripty.MsBuild.targets(27,5): error : at Microsoft.Build.Construction.ProjectRootElement..ctor(XmlReader xmlReader, ProjectRootElementCache projectRootElementCache, Boolean isExplicitlyLoaded)
Scripty.MsBuild.targets(27,5): error : at Microsoft.Build.Construction.ProjectRootElement.Create(XmlReader xmlReader, ProjectCollection projectCollection)
Scripty.MsBuild.targets(27,5): error : at Microsoft.CodeAnalysis.MSBuild.ProjectFileLoader.<LoadProjectAsync>d__5.MoveNext()
Scripty.MsBuild.targets(27,5): error : at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
Scripty.MsBuild.targets(27,5): error : at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Scripty.MsBuild.targets(27,5): error : at Microsoft.CodeAnalysis.MSBuild.ProjectFileLoader.<LoadProjectFileAsync>d__3.MoveNext()
Scripty.MsBuild.targets(27,5): error : at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
Scripty.MsBuild.targets(27,5): error : at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
It seems like Roslyn tries to load all projects in the solution and then encounter some of those new csproj files and then crash.
I was trying to see if I could get Scripty to work in a .NET Core project by creating a dummy full framework project that links to my Core project and then configuring Scripty in that project instead. I think this could be a potential workaround for .NET Core support if this error could be fixed.
@kawazoe Thanks for the additional info. My plan at the moment is to update everything to the latest and greatest, including the Roslyn bits Scripty uses internally. I'm hoping that will resolve issues with new csproj formats and the like since it was all updated for the VS 2017 release.
@daveaglick,
With the release of .NET Core 2, Do you think it is time to support?
Know you are busy, but any update on this? We are moving to .NET Core for all of our libraries and would like to move away from T4, but if this won't be updated soon...we will probably just move onward with T4.
Work is ongoing at a rapid pace (even though it doesn't look like it in this repo). Most of the effort right now is happening in Buildalyzer. That will become the basis for Scripty to load information about host projects regardless of project type or platform (right now there's literally no way to do this reliably). Once it's done, I'll begin rewriting Scripty to use Buildalyzer and multi target the SDK and traditional MSBuild tooling.
As for timing, I don't have any sort of estimate for you. I'm still a few weeks from finishing Buildalyzer and rewriting the Scripty MSBuild task and I'm not sure how long it will take once I start. It's moving along, but it's moving along at OSS speed.
I'm looking forward to the release. I am currently using dotnet core 2.0. It was working well for me with dotnet core 1.1, and has stopped returning any documents in 2.0.
Hi, What is the status of this?
Scripty.MSBuild was running fine until I started to load assemblies that target .net standard 2.1 and doing some reflection on the types inside. I have made a workaround creating a console application (.Net Core 3.1) that calls Scripy.Core runnning all the csx files in a specified target project folder. Even though the compiler complains about the Scripty-nuget getting restored using .net framework.
Are you planning to creating any new nuget releases? I saw someone created a fork and released ScriptyPlus.Core. Is that the same code?
BR Mikael
What is the status of this?
I just updated the readme with the following language:
Please note: it's been a while since a Scripty release. I'm not entirely sure when (or if) development on this project will resume. While I would love to pick up development here again at some point, I don't know if it makes sense to dedicate any more time given that the Roslyn team has committed to ship source generators as part of .NET 5.
In the meantime some other projects in this area include:
Are you planning to creating any new nuget releases?
Maybe...though I'd say it's doubtful at this point. While I really had intended to pick this back up after finishing some long release pushes on my other projects, my enthusiasm has lessened quite a bit with the Roslyn source generator work. It fills the same niche and there's no reason to duplicate effort that Microsoft is doing to add a similar capability in-the-box.
I saw someone created a fork and released ScriptyPlus.Core. Is that the same code?
This is the first I've heard of a fork :). I'd assume it started out as the same code and they've added/updated it. Yay for open source (though it would have been nice if they'd contacted me before releasing a fork to NuGet).
Scripty works with Visual studio code (.NET Core) as T4 cross platform alternative or not ?