Provide the new .NET4-compatible executable #147
Conversation
|
This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation. |
|
So the artifact has been deployed successfully: https://ci.appveyor.com/api/buildjobs/53mp3l80y46drwr5/artifacts/src%2FCore%2FServiceWrapper_dotNET4%2Fbin%2FRelease%2Fwinsw.exe It passes manual spot-checks, but I will appreciate additional reviews and testing |
| <Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" /> | ||
| </Target> | ||
| <!-- Merge plugins and other DLLs into winsw.exe --> | ||
| <UsingTask TaskName="MSBuild.Community.Tasks.ILMerge" AssemblyFile="$(SolutionDir)\packages\MSBuildTasks.1.4.0.88\tools\MSBuild.Community.Tasks.dll" /> |
There was a problem hiding this comment.
Maybe I should stop playing with ILMerge, because it's not that good at merging Debug symbols
|
Retriggering the CI |
|
Self-:bug:. Generated executable filenames should be different in order to support the deployment on Appveyor |
|
I declare @reviewbybees done since I want to unblock the further changes in the build flow. This change does not actually change the code itself. |
According to the requests, it is not always convenient to declare the
.NET Framework 4support inexe.config. Such approach also does not guarantee that the executable is really operational in this framework.This PR adds a new project, which generates a binary targeting
.NET Framework 4.0.Edited by @NextTurn: Fixes #103, fixes #112, fixes #102
@reviewbybees