Project.Build for Scripty.MsBuild doesn't preserve property values about scripty

[daveaglick]

@iskiselev Thanks for the recent bug reports - I'll try and do some issue triage and take a closer look at them all tomorrow.

If I recall, I was forced to shell out to a console application because MSBuild will not run two builds in the same process space. Roslyn requires MSBuild to run in order to populate the semantic model that Scripty provides, so the only options were to shell out the Roslyn compilation stage (and the rest of the Scripty execution) or mess with inner-process communication.

I opted for the former having had bad experiences with complex data and process boundaries in the past. Hopefully the fix is as simple as passing the current build configuration to the console application as an argument/arguments.

[reduckted]

I've just run into what I think is the same problem. I have this in my project file:

<Import Project="$(SolutionDir)\build\targets\Common.settings.targets" />

The solution contains many projects, so I'm using this targets file to define all of the common properties of the projects.

When I compile using Scripty.MsBuild, I get this error:

Microsoft.Build.Exceptions.InvalidProjectFileException: 
The imported project "C:\build\targets\Common.settings.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

This error certainly makes it look like the $(SolutionDir) variable is undefined within Scripty, so it sounds like the same problem.

[StingyJack]

I was able to get to this property while working with scripts that are part of a visual studio project. My use case is for in-project design time code generation like a T4, and the resulting .cs gets compiled into the dll/exe, etc. I don't use MsBuild outside of Visual Studio calling it, so I'm not sure if this works for your use case.

Near the top of the csx marked as CustomTool = ScriptyGenerator, I put this block of code to effectively short circuit the regeneration.

var regenFile = ShouldRegenOccur(Context);
if (regenFile == false)
{
    //wish there was access to put messages back to the caller
    // or intercept the call to EvaluateScript() without needing to do this.
    // Advice or suggestions welcome, but a pull request may be incoming for ScriptGenerator
    WriteExistingOutputFileBackToItself(Context);
    return;
}

These are in a separate csx file

using System.Linq;

#region "regeneration helpers"

public const string BUILD_CONFIG_NEEDED_TO_RUN_CODE_GEN = "RegenCodeFiles";

public bool ShouldRegenOccur(ScriptContext context)
{
    try
    {
        var activeProjectConfiguration = GetActiveProjectConfiguration(context);
        return BUILD_CONFIG_NEEDED_TO_RUN_CODE_GEN.Equals(activeProjectConfiguration, StringComparison.OrdinalIgnoreCase);
    }
    catch (System.Exception)
    {
        //ignoring for now
    }
    return false;
}

public string GetActiveProjectConfiguration(ScriptContext context)
{
    var projectCollection = Microsoft.Build.Evaluation.ProjectCollection.GlobalProjectCollection;
    var thisProj = projectCollection.LoadProject(context.Project.FilePath);
    var currentSlnCfg = thisProj.GlobalProperties["CurrentSolutionConfigurationContents"];
    var projectConfigs = System.Xml.Linq.XDocument.Parse(currentSlnCfg);
    var thisProjectNode = projectConfigs.Root.Descendants("ProjectConfiguration").FirstOrDefault(p => p.Attribute("AbsolutePath").Value == Project.FilePath);
    var projBuildValue = thisProjectNode.Value;
    var splits = projBuildValue.Split('|');
    var win = splits[0];
    return win;
}

public void WriteExistingOutputFileBackToItself(ScriptContext context)
{
    var fileName = System.IO.Path.ChangeExtension(context.ScriptFilePath, ".cs");
    context.Output.Write(System.IO.File.ReadAllText(fileName));
}

public string GetGenerationHeader()
{
    return $"// Generated at {DateTime.UtcNow} UTC by {Environment.UserName}";
}

#endregion //#region "regeneration helpers"