2

Closed

Fixes required to make NuGet work seamlessly on MonoDevelop

description

Note: All of this is related to the Visual Studio generated nuget files - I'm sorry if this is the wrong place to report this, in that case please let me know where I should report his.

I'm right now setting up a project under MonoDevelop on OS X and even though NuGet already has some features that should make it work, there are some glitches, which I hope to collect and this issue. A good reference is also mrward/monodevelop-nuget-addin#7

Assuming you're adding NuGet to a solution on Windows/VS, you run into the following issues:
  • Unix filesystems are case-sensitive. This breaks nuget.targets as the casing inside the file is assumed to be all lower case whereas the files added to a solution in the .nuget folder are cased like "NuGet".
  • RequireRestoreConsent is false by default: This is a small hurdle and can be easily worked around by the user by either fixing nuget.targets, but is there a better way?
  • Package restore puts the package folder in a weird location, $(SolutionDir)/ /packages (yes, theres a single whitespace folder in between). The reason is that there's a trailing whitespace in nuget.targets in after
$(SolutionDir) in <RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)" $(RequireConsentSwitch) -solutionDir "$(SolutionDir) "</RestoreCommand>
Unfortunately, this whitespace is required on windows as you'll get a "Illegal Character in Path" exception from msbuild (haven't looked into why that's the case). My hacky workaround:
<SolutionDirForPlatform Condition=" '$(OS)' == 'Windows_NT'">"$(SolutionDir) "</SolutionDirForPlatform >
<SolutionDirForPlatform Condition=" '$(OS)' != 'Windows_NT'">"$(SolutionDir)"</SolutionDirForPlatform >

<RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)"  $(RequireConsentSwitch) -solutionDir $(SolutionDirForPlatform)</RestoreCommand>
Closed Jun 25, 2013 at 8:53 PM by RanjiniM
Closing since workarounds have been suggested.

comments

eto wrote May 1, 2013 at 4:51 PM

Note that I found adding a trailing backslash to the RestoreCommand, instead of a space, works for both windows and mono on osx. Mono automatically changes the backslash to a forward slash on *nix based systems. I found it was creating a new blank folder under the solution directory without this change:

<RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)" $(RequireConsentSwitch) -solutionDir "$(SolutionDir)\"</RestoreCommand>

I'm not entirely sure why a space is required at the end of the solution dir to begin with, perhaps that should be fixed instead? On windows it does not seem to work without either the space or trailing backslash.

lextm wrote May 2, 2013 at 7:24 AM

I don't have a Mac, but isn't it similar to the case of running NuGet on Linux? Before NuGet 2.5, I found that the necessary steps to run NuGet on Linux,

http://www.lextm.com/2013/01/how-to-use-nuget-on-mono-part-i.html
http://www.lextm.com/2013/01/how-to-use-nuget-on-mono-part-ii.html

Since NuGet 2.5 has been released which resolves most of the known issues, you should now start from scratch or using the 2.5 version of NuGet.exe and NuGet.targets. That should fix the casing and package folder path issue.

As I showed in part II, you are recommended to use export command to set environment variable EnableNuGetPackageRestore in your build script. I don't think leaving the default setting as false is a problem.