CakeExecuteScript access denied errors on mono/mac #1247
Comments
|
Regression seems to be in the 4.5 Cake.xe assembly created by .NET Core and that Mono can't auto identify these as .NET/Mono assemblies. Mono has no issue executing said assembly when frame A workaround is to specify the runtime to use for execution public static CakeSettings GetCakeSettings(ICakeContext context, IDictionary<string, string> arguments = null)
{
var settings = new CakeSettings { Arguments = arguments };
if (context.Environment.Runtime.IsCoreClr)
{
settings.ToolPath = FindToolInPath(context, context.IsRunningOnUnix() ? "dotnet" : "dotnet.exe");
settings.ArgumentCustomization = args => "./tools/Cake.CoreCLR/Cake.dll " + args.Render();
}
else if (context.IsRunningOnUnix())
{
settings.ToolPath = FindToolInPath(context, "mono");
settings.ArgumentCustomization = args => "./tools/Cake/Cake.exe " + args.Render();
}
return settings;
}
public static FilePath FindToolInPath(ICakeContext context, string tool)
{
var pathEnv = context.EnvironmentVariable("PATH");
if (string.IsNullOrEmpty(pathEnv)||string.IsNullOrEmpty(tool))
{
return tool;
}
var paths = pathEnv.Split(new []{context.IsRunningOnUnix() ? ':' : ';'}, StringSplitOptions.RemoveEmptyEntries);
return paths.Select(
path=>new DirectoryPath(path).CombineWithFilePath(tool)
).FirstOrDefault(filePath=>System.IO.File.Exists(filePath.FullPath));
}But this would only solve that tool, potentially as more .NET tools start to utilize .NET the more tools will start to fail on Mono. We could introduce some magic in Tool / ToolSettings base, feels like a real potential rabbit hole though. What we could do is somekind of runtime / framework option on the base settings class which perhaps could have Native as default and i.e. .NET Core / Mono / Java as alternatives Or just a FrameworkToolPath. Perhaps we could add something to the tool registration to infer/let user specify runtime. Tool aliases could potentially be aware of supported runtimes got it's specific tool an register that. But this needs some thought, regardless ability to specify a tool runtime would be a good addition, if we make it "easy" for us it could be an "RuntimeToolPath" if not null used as process. |
|
Here's a bit more information gathered... There’s a bug i filed about this: https://bugzilla.xamarin.com/show_bug.cgi?id=44937 Essentially the trouble area is: https://github.com/mono/mono/blob/master/mono/io-layer/processes.c#L500 In that if statement, Now, the question: is mono’s interpretation of what’s managed or not incorrect, or is dotnetcore emitting an assembly with an incorrect CLR header? |
|
@Redth found a workaround, will PR shortly. |
devlead
added a commit
to devlead/cake
that referenced
this issue
Oct 10, 2016
This fixes cake-build#1247, because issue in .NET Core tooling AnyCPU needs to be specified
devlead
added a commit
to devlead/cake
that referenced
this issue
Oct 10, 2016
This fixes cake-build#1247, because issue in .NET Core tooling AnyCPU needs to be specified
devlead
added a commit
to devlead/cake
that referenced
this issue
Oct 10, 2016
This fixes cake-build#1247, because issue in .NET Core tooling AnyCPU needs to be specified
devlead
added a commit
to devlead/cake
that referenced
this issue
Oct 10, 2016
This fixes cake-build#1247, because issue in .NET Core tooling AnyCPU needs to be specified
akoeplinger
added a commit
to akoeplinger/mono
that referenced
this issue
Oct 10, 2016
… process We weren't checking whether a PE file is in PE32 or PE32+ format, causing us to use the PE32 offsets on the newer format as well. This means that using Process.Start() on a managed assembly didn't always work when a PE32+ file was in play. Such a file is created when targeting x64 e.g. via the -platform:x64 csc.exe/mcs option. The reason why we probably didn't notice until now is that in an assembly produced by mcs there happens to be some data at the PE32 CLR header offset even in a PE32+ file, causing the check to "work". This doesn't apply to csc.exe/roslyn though and so we couldn't execute those assemblies via Process.Start() even though they're perfectly managed. Since the .NET Core project.json toolchain produces x64-targeted assemblies by default more people ran into the issue trying to run those on Mono: cake-build/cake#1247 Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44937 PE/COFF spec at https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx
|
Fixed by #1266 |
|
@Redth v0.16.2 is now available on nuget which addresses this issue. Big thanks to you for finding this and @akoeplinger who helped us sort this. |
akoeplinger
added a commit
to mono/mono
that referenced
this issue
Oct 11, 2016
… process We weren't checking whether a PE file is in PE32 or PE32+ format, causing us to use the PE32 offsets on the newer format as well. This means that using Process.Start() on a managed assembly didn't always work when a PE32+ file was in play. Such a file is created when targeting x64 e.g. via the -platform:x64 csc.exe/mcs option. The reason why we probably didn't notice until now is that in an assembly produced by mcs there happens to be some data at the PE32 CLR header offset even in a PE32+ file, causing the check to "work". This doesn't apply to csc.exe/roslyn though and so we couldn't execute those assemblies via Process.Start() even though they're perfectly managed. Since the .NET Core project.json toolchain produces x64-targeted assemblies by default more people ran into the issue trying to run those on Mono: cake-build/cake#1247 Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44937 PE/COFF spec at https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx (cherry picked from commit 68bcbb4)
vip32
added a commit
to vip32/cake
that referenced
this issue
Oct 14, 2016
octo channel tests added + some more octo.exe settings to start a deployment after creating the release. http://docs.octopusdeploy.com/display/OD/Creating+releases Waiting for AppVeyor process to exit * aslo validates exit code * added sample code * fixes cake-build#1241 comment fix another channel comment fix settings again Corrects the grammar "do/does" in exception messages and tests Removed unused integration test code Change to use AnyCPU to address mono issue This fixes cake-build#1247, because issue in .NET Core tooling AnyCPU needs to be specified (build) Updated version and release notes Fixed unquoted VSTest settings file, now using AppendSwitch* Removed erroneous apostrophes Added % to alphanumeric chars allowed in glob Adds /LogFile parameter to DotCoverSettings Solves cake-build#1151
vip32
added a commit
to vip32/cake
that referenced
this issue
Oct 14, 2016
octo channel tests added + some more octo.exe settings to start a deployment after creating the release. http://docs.octopusdeploy.com/display/OD/Creating+releases Waiting for AppVeyor process to exit * aslo validates exit code * added sample code * fixes cake-build#1241 comment fix another channel comment fix settings again Corrects the grammar "do/does" in exception messages and tests Removed unused integration test code Change to use AnyCPU to address mono issue This fixes cake-build#1247, because issue in .NET Core tooling AnyCPU needs to be specified (build) Updated version and release notes Fixed unquoted VSTest settings file, now using AppendSwitch* Removed erroneous apostrophes Added % to alphanumeric chars allowed in glob Adds /LogFile parameter to DotCoverSettings Solves cake-build#1151 Waiting for AppVeyor process to exit * aslo validates exit code * added sample code * fixes cake-build#1241 another channel comment fix settings again Corrects the grammar "do/does" in exception messages and tests Removed unused integration test code (build) Updated version and release notes Fixed unquoted VSTest settings file, now using AppendSwitch* Removed erroneous apostrophes Added % to alphanumeric chars allowed in glob Adds /LogFile parameter to DotCoverSettings Solves cake-build#1151
vip32
added a commit
to vip32/cake
that referenced
this issue
Oct 14, 2016
octo channel tests added + some more octo.exe settings to start a deployment after creating the release. http://docs.octopusdeploy.com/display/OD/Creating+releases Waiting for AppVeyor process to exit * aslo validates exit code * added sample code * fixes cake-build#1241 comment fix another channel comment fix settings again Corrects the grammar "do/does" in exception messages and tests Removed unused integration test code Change to use AnyCPU to address mono issue This fixes cake-build#1247, because issue in .NET Core tooling AnyCPU needs to be specified (build) Updated version and release notes Fixed unquoted VSTest settings file, now using AppendSwitch* Removed erroneous apostrophes Added % to alphanumeric chars allowed in glob Adds /LogFile parameter to DotCoverSettings Solves cake-build#1151 Waiting for AppVeyor process to exit * aslo validates exit code * added sample code * fixes cake-build#1241 another channel comment fix settings again Corrects the grammar "do/does" in exception messages and tests Removed unused integration test code (build) Updated version and release notes Fixed unquoted VSTest settings file, now using AppendSwitch* Removed erroneous apostrophes Added % to alphanumeric chars allowed in glob Adds /LogFile parameter to DotCoverSettings Solves cake-build#1151 comment fix octo channel tests added + some more octo.exe settings to start a deployment after creating the release. http://docs.octopusdeploy.com/display/OD/Creating+releases Waiting for AppVeyor process to exit * aslo validates exit code * added sample code * fixes cake-build#1241 comment fix another channel comment fix settings again Corrects the grammar "do/does" in exception messages and tests Removed unused integration test code Change to use AnyCPU to address mono issue This fixes cake-build#1247, because issue in .NET Core tooling AnyCPU needs to be specified (build) Updated version and release notes Fixed unquoted VSTest settings file, now using AppendSwitch* Removed erroneous apostrophes Added % to alphanumeric chars allowed in glob Adds /LogFile parameter to DotCoverSettings Solves cake-build#1151 Waiting for AppVeyor process to exit * aslo validates exit code * added sample code * fixes cake-build#1241 another channel comment fix settings again Corrects the grammar "do/does" in exception messages and tests Removed unused integration test code (build) Updated version and release notes Fixed unquoted VSTest settings file, now using AppendSwitch* Removed erroneous apostrophes Added % to alphanumeric chars allowed in glob Adds /LogFile parameter to DotCoverSettings Solves cake-build#1151
picenka21
pushed a commit
to picenka21/runtime
that referenced
this issue
Feb 18, 2022
… process We weren't checking whether a PE file is in PE32 or PE32+ format, causing us to use the PE32 offsets on the newer format as well. This means that using Process.Start() on a managed assembly didn't always work when a PE32+ file was in play. Such a file is created when targeting x64 e.g. via the -platform:x64 csc.exe/mcs option. The reason why we probably didn't notice until now is that in an assembly produced by mcs there happens to be some data at the PE32 CLR header offset even in a PE32+ file, causing the check to "work". This doesn't apply to csc.exe/roslyn though and so we couldn't execute those assemblies via Process.Start() even though they're perfectly managed. Since the .NET Core project.json toolchain produces x64-targeted assemblies by default more people ran into the issue trying to run those on Mono: cake-build/cake#1247 Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44937 PE/COFF spec at https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx Commit migrated from mono/mono@68bcbb4
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What You Are Seeing?
Getting an access denied error
What is Expected?
No errors, secondary script should execute successfully
What version of Cake are you using?
0.16
Are you running on a 32 or 64 bit system?
x64
What environment are you running on? Windows? Linux? Mac?
Mac 10.11, Mac 10.12
Are you running on a CI Server? If so, which one?
N/A
How Did You Get This To Happen? (Steps to Reproduce)
build.cake:
two.cake:
Output Log
The text was updated successfully, but these errors were encountered: