Scripty
Scripty copied to clipboard
Trying to get to know Scripty - failing at the first sample projects already...
I'm trying to figure out if Scripty does what I need - but I can't even get beyond the simplest starter samples...
I tried this one:
MyScript.csx
foreach (Document doc in Project.Documents)
{
Output.WriteLine($"// {doc.FilePath}");
}
and I keep getting these errors:
-
Custom tool error: The type or namespace name 'Document' could not be found (are you missing a using directive or an assembly reference?)
-
Custom tool error: 'ProjectRoot' does not contain a definition for 'Documents' and no extension method 'Documents' accepting a first argument of type 'ProjectRoot' could be found (are you missing a using directive or an assembly reference?)
Any ideas what I'm missing? VS 2015 UPD3, .NET 4.6.2, ASP.NET Web project
Sorry for the delay, I tend to work this project in short bursts.
It looks like the Scripty.Core libraries aren't referenced. This may have something to do with the .NET 4.6.2 target. Are/were you attempting to run the script with the the MSBuild task (installed via NuGet) or the custom tool (installed via the Visual Studio gallery)?
I'm in the process of getting everything up to date to latest Roslyn, Visual Studio, etc. I'll drop a line here when that's done and let's see if helps.
Not sure it's related to 4.6.2 - get the same error with 4.6.1
@marc-at-nowhow @brijber I've just released a new version that refreshes all the referenced libraries. When either of you get a chance could you try it out and report back? Thanks!
Hi Dave, the newest version seems to work - provided you're using it in VS 2017. In VS2015 (my main environment), I keep getting an error on the "Scripty.CustomTool" relating to the reference to "Microsoft.VisualStudio.Shell.Framework" (only that one - all the others seem to be fine).
The error reads:
Error: The "GetExtensionsPath" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.Settings.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.VisualStudio.Settings.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' at Microsoft.VsSDK.Build.Tasks.GetExtensionsPath.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
I've not been able to use Scripty from vs2017 with the custom tool or scripty.msbuild so I thought I'd try out the command line option. I'm the same error with 0.7.1
Adding task to evaluate C:\_dev\ben\ConsoleApp1\ConsoleApp1\MyScript.csx
'ProjectRoot' does not contain a definition for 'Documents' and no extension method 'Documents' accepting a first argument of type 'ProjectRoot' could be found (are you missing a using directive or an assembly reference?) [0,38]
The type or namespace name 'Document' could not be found (are you missing a using directive or an assembly reference?) [0,9]
I'll try and dig into it more this week(end). I'm really looking forward to Scripty to replace our T4 stuff.
@marc-at-nowhow About to release 0.7.4 which will hopefully resolve the error you're seeing with pre-2017 Visual Studio versions. This VSIX packaging stuff is magic voodoo and I'm kind of figuring it out as I go.
@hyrmn Give 0.7.4 a try - I've been squashing a lot of binding failures and other bugs recently so hopefully it'll be a lot more stable for you.
Hi Dave, I tried the latest bits from the "develop" branch.
In VS 2013, it causes loads of errors, because you use the "string interpolation" feature of C# 6.0 ($"....") and those are all flagged as errors in VS 2013.
In VS 2015, those aren't flagged as errors, but I still keep getting:
Scripty.CustomTool:
Error: The "GetExtensionsPath" task failed unexpectedly.
System.IO.FileNotFoundException:
Could not load file or assembly 'Microsoft.VisualStudio.Settings.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the specified file.File name: 'Microsoft.VisualStudio.Settings.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at Microsoft.VsSDK.Build.Tasks.GetExtensionsPath.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
and one of the dependencies under "References" in the project is marked with an exclamation mark:
http://i68.tinypic.com/2j1wv1v.png
The version that is being referenced there is v15 which is actually for visual studio 2017.
I haven't got the same environment as you. Try building scripty in vs2015 and running the tests. Does it work? Are there missing references?
I'm running into this as well.
- Added
Scripty.MsBuild
from NuGet - Created
Test.csx
containing theforeach (Document document in Project.Documents)
example - Added
<ItemGroup><ScriptyFile Include="Text.csx" /></ItemGroup>
tocsproj
- Built solution
The output is
Scripty.MsBuild.targets(31, 5): [null] 'ProjectRoot' does not contain a definition for 'Documents' and no extension method 'Documents' accepting a first argument of type 'ProjectRoot' could be found (are you missing a using directive or an assembly reference?) [0,38]
This is in Visual Studio 2017.
@M-Pixel For your exact issue, try Project.Analysis.Documents
instead of Project.Documents
- the Project
global property has two child properties for accessing the underlying APIs: Analysis
for the Roslyn API and Build
for the MSBuild API.
For everyone else on this issue...
Scripty currently has a number of problems with different project type and target combinations, which I think is what most of you have been hitting. The underlying problem is that upstream libraries like MSBuild APIs and Roslyn's MSBuildWorkspace haven't been able to keep up with the rapid pace of change in .NET Core and the .NET Core SDK-style project system.
I recently finished Buildalyzer to deal with this exact problem and will be refactoring Scripty to use it in the near future. I've also got plans to rewrite some of the under-the-hood stuff. Between the two I hope to have a solid basis going forward.