[Mono-osx] Info.plist file location in MonoMac project

Michael Hutchinson m.j.hutchinson at gmail.com
Tue Feb 7 15:36:34 UTC 2012


On 7 February 2012 06:32, stevenspencer <stevenspencer01 at gmail.com> wrote:
>> Like other bundle resources, the relative path within the project
>> reflects the relative path in the app bundle. Anything else would be
>> inconsistent.
>>
>> I've bene considering providing a way to keep bundle resources
>> (including Info.plist) into a Resources subfolder in the project, to
>> aid project organization.
>
> Hi Michael,
>
> thanks for that. If you are currently thinking about this, can I put in a
> request?
>
> As I'm sure you are aware, when files get added to the project, their
> entries in the csproj file can look something like this:
>
>    <Compile Include="..\..\path\on\disk\file.cs">
>      <Link>path\in\project\file.cs</Link>
>    </Compile>
>
> i.e. when adding files to a project, you can "add as a link". In this case,
> the actual file resides somewhere else in the file system, as defined by the
> "Include" attribute, but the file appears to be organised within the project
> according to the path defined in the <Link> element, relative to the root of
> the project. In the case where a file is created in the same directory as
> the csproj, the file's actual path and its project path are effectively the
> same. It is the project path that determines how the file is organised
> within the project in the solution pane of MonoDevelop.
>
> Can I request that any build process uses these more abstract project paths
> in determining what files to build and where to put the outputs. This would
> mean that the organisation as seen in MonoDevelop would be the determining
> factor in how the project is built, which makes some sense to me and
> conforms to your initial statement of "the relative path within the project
> reflects the relative path in the app bundle". Then, the actual file paths
> would only ever be used to retrieve the contents of the file.
>
> Consider these files in a project as an example:
>
> /Info.plist                              ->        Builds to
> App.app/Contents/Info.plist
> /Resources/Image1.png           ->        Builds to
> App.app/Contents/Image1.png
> /Resources/Image2.png           ->        Builds to
> App.app/Contents/Image2.png
>
> The paths on the left are the project paths of the files i.e. these define
> how the files are organised in the solution pane of MonoDevelop. The actual
> locations of the files on disk could be anywhere. In this case, I think it
> is reasonable for the MonoDevelop build process to impose your statement of
> "the relative path within the project reflects the relative path in the app
> bundle". Just to clarify, I do **not** have a requirement that would do the
> following:
>
> /Some/Random/Folder/Info.plist             ->        Builds to
> App.app/Contents/Info.plist
>
> i.e. the Info.plist can appear anywhere within the project.
>
> Hope this makes sense and I'm not rambling too much. Maybe it is not really
> feasible for some other reason that I'm not aware of, but hopefully it is.

I'm pretty sure this "virtual project relative path" is already used
for content and interface builder files. However (unlike MonoTouch) it
doesn't currently seem to be used for Info.plist - I guess this was an
oversight.

I'd also been considering adding a "LogicalName", that would allow you
to override the bundle resource ID (i.e. Bundle-relative path)
regardless of the actual filename and project-relative path, like you
can set the resource ID for EmbeddedResource items.

-- 
Michael Hutchinson
http://mjhutchinson.com


More information about the Mono-osx mailing list