New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust Xamarin.iOS archive helper params. #693

Merged
merged 2 commits into from Mar 12, 2015

Conversation

Projects
None yet
4 participants
@patridge
Contributor

patridge commented Mar 12, 2015

Issue

When converting a Xamarin project from RAKE to FAKE, I was having issues using the XamarinHelper iOSArchive method. If I sent a project filename or fully-qualified path into the ProjectPath parameter, it would instead grab the nearest solution file and try to find that "path" as a project name. It turns out that parameter is used to name a project within a solution rather than a path.

Solution

Since mdtool can take both a project/solution file parameter and a project name parameter, I adjusted it to accept both.

  1. I renamed the old ProjectPath parameter to ProjectName to better reflect its purpose as a project name to find in a given (or fallback) solution.
  2. Since this name parameter isn't actually required by mdtool, the validation was no longer needed to require it be provided.
  3. I added a parameter for the project/solution path. Since this parameter is also not required by mdtool, it was configured to be optional (leaving mdtool to "pull the first solution it can find in the current directory".
  4. Restructured the mdtool calls to handle the new parameters

Tested

Here are some versions I was able to get to work with a simple Xamarin.Forms project I created with a solution at the same level as the build.fsx file being processed.

iOSArchive (fun defaults ->
    {defaults with
        SolutionPath = "SomeSolution.sln"
        ProjectName = "SomeProject.iOS"
        Configuration = "AppStore|iPhone"
    })
// => mdtool -v archive "-c:AppStore|iPhone" -p:SomeProject.iOS SomeSolution.sln

iOSArchive (fun defaults ->
    {defaults with
        ProjectName = "SomeProject.iOS"
        Configuration = "AppStore|iPhone"
    })
// Grabs local SomeSolution.sln and finds SomeProject.iOS within it
// => mdtool -v archive "-c:AppStore|iPhone" -p:SomeProject.iOS

iOSArchive (fun defaults ->
    {defaults with
        Configuration = "AppStore|iPhone"
    })
// Grabs local SomeSolution.sln which is configured to build SomeProject.iOS for this configuration.
// => mdtool -v archive "-c:AppStore|iPhone"

Potential Problems

  • Could be useful to output a debug message when no solution path is provided and mdtool will end up grabbing the first solution file it finds.

  • Although mdtool can build from a project file directly, I was getting errors trying to archive from one. So, while SolutionPath could potentially take a project path, the archive step appears to fail.

    ERROR: Failed to archive project. Argument cannot be null.
    Parameter name: inSolution
    Running build failed.

  • I'm still fairly new to F#, so my conditional logic to create an optional mdtool argument may not be ideal.

@forki

This comment has been minimized.

Member

forki commented Mar 12, 2015

@rflechner @gshackles @chrisriesgo since you worked on that helper, could you please help to review this? Thanks.

@chrisriesgo

This comment has been minimized.

Contributor

chrisriesgo commented Mar 12, 2015

@forki - Definitely

@chrisriesgo

This comment has been minimized.

Contributor

chrisriesgo commented Mar 12, 2015

@forki - I don't see any glaring issues with the update.

@gshackles

This comment has been minimized.

Contributor

gshackles commented Mar 12, 2015

Same here, though it's worth noting that this is a breaking change for anyone already using that method in the helper 😄

@patridge

This comment has been minimized.

Contributor

patridge commented Mar 12, 2015

Yeah...sorry about that. If it would be worthwhile to create some sort of deprecated stop-gap overload, I could certainly try to figure out a way to do it.

@forki

This comment has been minimized.

Member

forki commented Mar 12, 2015

what part is breaking exactly?

@gshackles

This comment has been minimized.

Contributor

gshackles commented Mar 12, 2015

Removing the old ProjectPath parameter in favor of ProjectName and SolutionPath. If this makes the behavior better then it's probably worth the break since it's pretty minimal.

Full disclosure: I'm not using that method myself 😀

@chrisriesgo

This comment has been minimized.

Contributor

chrisriesgo commented Mar 12, 2015

And I was using it, but I'm not anymore.

forki added a commit that referenced this pull request Mar 12, 2015

Merge pull request #693 from patridge/XamarinHelper-ArchiveFix
Adjust Xamarin.iOS archive helper params.

@forki forki merged commit f8694df into fsharp:master Mar 12, 2015

2 checks passed

continuous-integration/appveyor AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment