[Mono-list] [mono-list] Merging compiled SVN with installed version.

[Eric Morgan]

SEbastien (sorry, mis-spelled it last time.. :o)

I'm working on a test case right now.  I don't know how long it will take,
because I think the problem is in the UserControl part.  We have custom
controls inherited from other custom controls using custom pain objects with
custom paint methods.  These are crammed into giant complex, panelled MDI
windows.  Reproduction may not even be possible - I didn't even write the
code in the first place.  I better get my shovel, cause it's time to dig
like crazy.

You can see screenshots of our software (running with mono no less) at
www.rengeo.com/linux
You might get some idea of what I'm talking about, how complex our controls
are.


> ah, it's not managed code :|
> and probably not (much) mono-aware so it consider mono as the "root"
> executable.
>
> Maybe (untried) you can consider having a wrapper executable to call the
> runtime ? (instead of your own mono ?)


You mean have .NET code call a shell script or something which runs mono
with our executable?  Something similar?  That sounds hackish to me...  We
have a shell script that runs our program with mono automatically.  Wouldn't
it end up in a magic circle of .NET runtimes?  I'd need mono to call the
.NET exe, which calls mono calling a .NET exe.  The executing program would
still be mono..  Is there some shell script magic I can do?  Fork or exec?
Now that I think about it, my shell script execs mono..  Hrmm, I'll play
around with that one a little.  I still remember learning about a "fork
bomb" in my OS class at school, and fork still scares me today which is why
I'm avoiding it.


> I even contacted them and they told us "sorry, no other option than
> > that .xml file in the same directory".  Without that licensing, our
> > software won't run, so I think it's major enough that we request write
> > permission to those directories.
>
> If that's an install-time only issue then you should require someone
> with su privileges to install the software. If you need to write at
> every execution time then it's not an option.


That file contains server info, port info, and other configuration stuff to
contact a network license server.  It's written out every time they change
those options in the program.  So, it's not only an install-time issue.  I
might be able to force it as such, but the amount of support calls I'm going
to get with people not being able to change the license server they are
using without a system administrator scares me a little...  :/


> Is this a HUGE security issue or something?
>
> That depends on how you fix it. Having a local mono install isn't a
> security issue - but modifying /usr/bin directory permissions could be.


I would not advise them to modify their /usr/bin directory permissions.  I
try to tell them to install mono in a local self-contained folder within
/usr/local or /opt or something.  Then, change the permissions of certain
sub-directories in there.  I can't see that being a security issue, but I
could easily be wrong.



>
> > Just tried with my synchronized version of SVN HEAD (r74177), and it
> > performs the exact same behavior as I'm describing.  :/
>
> Good news, it's not your fault ;-)
> Now it's time to fill a bug report :|


:(  test-case time.  I'll see if I can get something.  Here's a question:
Would a screenshot of the issue (it's very visible) help at all in the mean
time?  Maybe I can get lucky and someone will go "hey, I know why it's doing
that!!"...


Thanks for all your help!  Really appreciate it!

Eric Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20070313/0d233a54/attachment-0001.html