<div>Throwing may be better if the framework is missing.  I can be convinced.</div><div>No symlinking for now.</div><div><br></div><div>The &quot;relative path&quot; option is only while developing and has no impact when running.  Once installed into Contents\Frameworks the reference is always relative to the app location.</div>
<div><br></div><div>Incorporated most of your suggestions, out of time now have to get back to the day job.  Also added the ability for the project pad to update as frameworks are added/deleted.  This is the same basic method Web References uses.</div>
<div><br>Did not move the generation of the file to OnBuild.  But it is better about not requiring a build every time.</div><div><br></div><div>The generated path in the dlopen call is almost correct.  Currently it is the FULL path to the &lt;proj&gt;.app\Contents\Frameworks location.  Which is incorrect.  The call to dlopen should be relative to the .app&#39;s location.</div>
<div><br></div><div>Including the new files.</div><div><br></div><div>Even though I disagree in part to the overuse of var I did modify this code to use it more.</div><div><br></div>I disagree with using var when the type is known.  To me that is exactly when you should not use var and diminishes one of C#&#39;s benefits, strong name typing.  At least from readability.<div>
<br></div><div>I agree with this summary from <a href="http://www.infoq.com/news/2008/05/CSharp-var">http://www.infoq.com/news/2008/05/CSharp-var</a>:</div><meta charset="utf-8"><div><meta charset="utf-8"><span class="Apple-style-span" style="font-family: Lucida, &#39;Lucida Grande&#39;, Tahoma, sans-serif; font-size: 13px; line-height: 16px; "><blockquote style="border-top-width: 2px; border-right-width: 2px; border-bottom-width: 2px; border-left-width: 2px; border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-top-color: rgb(239, 239, 239); border-right-color: rgb(239, 239, 239); border-bottom-color: rgb(239, 239, 239); border-left-color: rgb(239, 239, 239); padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; margin-right: 0px; margin-left: 20px; color: rgb(51, 51, 51); background-image: url(http://cdn1.infoq.com/styles/i/bg-blockquote.gif); background-attachment: initial; background-origin: initial; background-clip: initial; background-color: rgb(250, 250, 250); background-position: 5px 5px; background-repeat: no-repeat no-repeat; ">
<p>Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types.</p>
</blockquote></span><div>For example this line is completely vague:</div><div>var ls = conf.LaunchScript;</div><div><br></div><div>I do not know what ls is.  What is a LaunchScript, oh if I hover over it I see it is a FilePath.  To be me that would much more readable and useful as:</div>
<div>FilePath ls = conf.LaunchScript;</div><div><br></div><div>That makes the code clear just from a glance.  Otherwise I have to research to determine the type.  Maybe if you limit the use to var foo = new Foo ().  But not everywhere especially when the assignment is vague.</div>
<div><br></div><div>Duane</div><div><br><div class="gmail_quote">On Wed, Jan 26, 2011 at 6:52 PM, Michael Hutchinson <span dir="ltr">&lt;<a href="mailto:m.j.hutchinson@gmail.com">m.j.hutchinson@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Jan 26, 2011 at 10:01 AM, Duane Wandless &lt;<a href="mailto:duane@wandless.net">duane@wandless.net</a>&gt; wrote:<br>

&gt; Thanks, here is another update based on feedback.<br>
&gt; Changes:<br>
&gt; * renamed the menu item<br>
&gt; * save to the project file as MSbuild items<br>
&gt; * use CodeDOM to generate code<br>
&gt; * generates MonoMacFrameworks.Initialize() in MonoMacFrameworks.cs<br>
&gt; * saves to project whether relative or absolute path<br>
&gt; * relies on MonoMac exporting dlopen and dlerror in<br>
&gt; the MonoMac.ObjCRuntime.Dlfcn class<br>
&gt; Issues:<br>
&gt; * Project pad does not update when frameworks are added/deleted<br>
&gt; * build must always be performed since build process modifies<br>
&gt; MonoMacFrameworks.cs in wrong step<br>
&gt; * UI needs more work<br>
<br>
</div>Great, this is definitely moving quickly in the right direction :)<br>
<br>
A few more comments:<br>
* your patch is missing the added files - it only has the modified files.<br>
* please move the CodeDom code into a separate method<br>
* you should update the generated file before the base.OnBuild call,<br>
so it happens before the compilation<br>
* it might be nice to update the generated code immediately after any<br>
frameworks are added/removed. Not a must-have though.<br>
* you should only copy the frameworks if they change<br>
* the generated file should only be updated at build time if the<br>
project file is newer than the generated file. GetNeedsBuilding should<br>
check this too.<br>
* don&#39;t hardcode CSharpCodeProvider, you can get the appropriate<br>
language-specific CodeDomProvider from the DotNetProject.<br>
* please use var when the type is obvious from the assignment,<br>
especially newing, e.g. var foo = new FooBar (...);<br>
* property initializers can be used to make CodeDom a bit nicer.<br>
* if (Directory.Exists (destFramework) == true) should be if<br>
(Directory.Exists (destFramework))<br>
* wouldn&#39;t it be better to throw instead of writing a console message,<br>
since missing frameworks will almost certainly break an app?<br>
* partial modifiers are no longer needed<br>
* string paths can be implicitly cast to/from MD&#39;s FilePath struct,<br>
which neatens up path manipulation a bit<br>
* should there be a distinction for &quot;local copy&quot; frameworks, like dll<br>
references have? In both cases you need the loading code, but only for<br>
local copy does the framework need to be copied into the app AFAIK.<br>
<br>
Re. Miguel&#39;s comments, it would be good to check for missing<br>
frameworks when copying them and return errors in a BuildResult<br>
instead of letting MD present the IO exception directly.<br>
<br>
I&#39;m not sure about the symlinking, since the apps we build are<br>
currently distributable without additional packaging steps, and<br>
symlinking would break that. Frameworks won&#39;t really hurt build<br>
iteration times if we fix it to to only copy frameworks when they<br>
change.<br>
<font color="#888888"><br>
--<br>
Michael Hutchinson<br>
<a href="http://mjhutchinson.com" target="_blank">http://mjhutchinson.com</a><br>
</font></blockquote></div><br></div></div>