Fix windows build process, manostool improvements #126
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…, so windows users don't have to modify the project file to build.
…based on that. Add error message when --init is run without any AppName Specify tool name (manostool) in a static field so we're not writing the tool name over and over.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These commits modify the .csproj file for the Manos project to specify that the Mono.* dlls are located in the same lib directory as the Nini.dll file, so windows users can just grab those dlls and place them in the lib directory to build. This won't change the mono build process since those assemblies are already in the GAC.
I didn't bundle the dlls themselves in these commits since they are quite large, and we probably want users to get them for themselves, although the Mono.CSharp assembly is a little in-limbo with API changes, so bundling 2.8's version might be wise.
This also changes Environment to add an IsWindows property, so we can switch the manostool --se ouput for different platforms, since the environments differ on windows and *nix. This also adds an error if --init is called with no argument, and moves the name of the tool (manostool) to a static field so we don't have to write the tool name over and over, and it can be easily changed.