While filing http://bugs.winehq.org/show_bug.cgi?id=7098 I realized that I'm starting to see lots of apps that require dot net, and there are two ways we could go to support them: 1) get msft's dotnetfx.exe to install (see http://bugs.winehq.org/show_bug.cgi?id=5358) and work 2) whip our mono integration into shape (see http://kegel.com/wine/fakedotnet.sh )
The question is, how should we tag bugs in bugzilla that fail because neither of these approaches really work yet? Should we make them depend on bug 5358, or should we create a new bug component, wine-dotnet11 or wine-mono, and put them in there? Filing these bugs as wine-misc seems wrong, so I'm leaning towards a new bugzilla component. - Dan
Dan Kegel wrote:
While filing http://bugs.winehq.org/show_bug.cgi?id=7098 I realized that I'm starting to see lots of apps that require dot net, and there are two ways we could go to support them:
- get msft's dotnetfx.exe to install (see
http://bugs.winehq.org/show_bug.cgi?id=5358) and work 2) whip our mono integration into shape (see http://kegel.com/wine/fakedotnet.sh )
The question is, how should we tag bugs in bugzilla that fail because neither of these approaches really work yet? Should we make them depend on bug 5358, or should we create a new bug component, wine-dotnet11 or wine-mono, and put them in there? Filing these bugs as wine-misc seems wrong, so I'm leaning towards a new bugzilla component.
- Dan
I think that it should be a component. I would say wine-dotnet.
--
Tony Lambregts
Tony wrote:
I think that it should be a component. I would say wine-dotnet.
Suits me. All in favor? - Dan
Dan Kegel wrote:
Tony wrote:
I think that it should be a component. I would say wine-dotnet.
Suits me. All in favor?
No, components are for parts of Wine. .net is not part of Wine and won't be for some time. I think having a meta bug for now should suffice. That's one part of bugzilla we are not using so well - the dependencies.
Vitaliy.
Vitaliy wrote:
No, components are for parts of Wine. .net is not part of Wine and won't be for some time.
Hrm. Seems to me mono is going to become an important part of wine pretty soon, if it lets us run .net applications. But whatever. How would you feel about creating a category for mscoree, which is definitely part of Wine, and where the mono integration bugs are generally located? - Dan
Hello!
Hrm. Seems to me mono is going to become an important part of wine pretty soon, if it lets us run .net applications.
What would have to be done to make MS .net work with wine? I think MS .Net might be better a better coice -- when thinking of compatibility -- especially in connection with the latest VisualStudio.
Ciao,
Olaf
Olaf wrote:
Hrm. Seems to me mono is going to become an important part of wine pretty soon, if it lets us run .net applications.
What would have to be done to make MS .net work with wine? I think MS .Net might be better a better choice-- when thinking of compatibility -- especially in connection with the latest
VisualStudio.
I think it's been poked at a bit, and ought to be doable. It's probably a month or so's concentrated work by some wine developer. I'd like to see it happen, but it's always risky to get hooked on MS code that could be withdrawn or made incompatible with Wine; better to spend the effort getting the Mono route working first, especially since it looks like that's really close. If you want to try it, here's a shell script that installs mono and sets up the registry keys needed for Wine to use it for .net programs: http://kegel.com/wine/fakedotnet.sh - Dan
On Sun, 7 Jan 2007 09:16:31 -0800 "Dan Kegel" dank@kegel.com wrote:
Olaf wrote:
Hrm. Seems to me mono is going to become an important part of wine pretty soon, if it lets us run .net applications.
What would have to be done to make MS .net work with wine? I think MS .Net might be better a better choice-- when thinking of compatibility -- especially in connection with the latest
VisualStudio.
I think it's been poked at a bit, and ought to be doable. It's probably a month or so's concentrated work by some wine developer. I'd like to see it happen, but it's always risky to get hooked on MS code that could be withdrawn or made incompatible with Wine; better to spend the effort getting the Mono route working first, especially since it looks like that's really close. If you want to try it, here's a shell script that installs mono and sets up the registry keys needed for Wine to use it for .net programs: http://kegel.com/wine/fakedotnet.sh
- Dan
Hmmm... gtk-sharp demos seem to work -- but since gtk switched to cairo fonts are wrong(*) in gtk apps which run in wine. Some time ago I could run gimp in wine (well, it needed the paths to be set correctly and the exe-plug-ins being removed). This was with gtk-2.6 (without cairo) and the fonts where okay.
I also wrote a small scalar-product-benchmark which was similar slow compared to "native" mono. ;-)
Ciao, Olaf
(*): They are to big. I think I should post a bug report... maybe tomorrow -
(*): They are to big. I think I should post a bug report... maybe tomorrow -
Not tomorrow -- but now:
-
Dan Kegel -
Olaf Leidinger -
Tony Lambregts -
Vitaliy Margolen