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

[Sebastien Pouliot]

Hey,

On Tue, 2007-03-13 at 15:53 -0600, Eric Morgan wrote:
> 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 should really move this part of the conversation to
mono-winforms-list. You're missing a lot of potential helpers right now.

> 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. 

Looks very nice. I'm curious, are you using System.Drawing, directly or
indirectly (3rd parties), for the graphs ?

>         
>         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?

no

>   Something similar?  

Yes, having another native executable call mono (wrapper). This new root
executable would be in your control (install anywhere), could detect an
already installed (and compatible) Mono installation (if you like) and
would (probably) be the root executable for your licensing software (no
more messing with someone else permissions).

> That sounds hackish to me...  

Maybe, but I would prefer that to messing with my existing file-system
permissions.

> We have a shell script that runs our program with mono automatically.
> Wouldn't it end up in a magic circle of .NET runtimes?  

No, it would be a native executable (not a .net one) and *could* replace
some shell scripts you have (but that's not a good reason in itself).

> 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?  

Maybe. It all depends on how the licensing software you're using detect
the root executable.

> Now that I think about it, my shell script execs mono..  Hrmm, I'll
> play around with that one a little.  

It's only a suggestion around the first problem you mentioned
(permissions).

> 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...  :/ 

Yes. OTOH if people don't have su privileges then it's unlikely the
sysadmins will want to change things like /usr/bin permissions (if
that's indeed what you do). 

Anyway you know your clients much better than me ;-) My only point is
that it's normal (i.e. not a bug), in certain cases, that you're not
able to write where the mono executable is located.

>         > 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. 

It system/distro specific. Some directories can take precedence
over /usr and/or are shared so it (changing permissions) could introduce
problems. It may be better to have a very local (under home) mono setup.
Again the devil, if any, is in the details ;-)

>         > 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!!"...  

Maybe, send it (or better a link* to it) to mono-winforms-list.

(*) if too large your message (including attachments) will need
moderator approval (delays).

>  
> Thanks for all your help!  Really appreciate it!

No problem :)
Sebastien

> Eric Morgan
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list