re: wine.inf: added .NET InstallRoot key
What is our intent with adding all these registry keys? It seems as if they are helpful for installing mono, but might get in the way of installing MS .net. If that's the intent, do y'all want me to make the dotnet20 winetricks verb remove any registry keys that confuse the dotnet20 installer?
Dan Kegel <dank(a)kegel.com> writes:
What is our intent with adding all these registry keys? It seems as if they are helpful for installing mono, but might get in the way of installing MS .net.
If they prevent installing MS .NET there should be a way to undo them like we do for IE, by unregistering mscoree or something along those lines. -- Alexandre Julliard julliard(a)winehq.org
On Tue, Aug 24, 2010 at 1:52 PM, Alexandre Julliard <julliard(a)winehq.org> wrote:
What is our intent with adding all these registry keys? It seems as if they are helpful for installing mono, but might get in the way of installing MS .net.
If they prevent installing MS .NET there should be a way to undo them like we do for IE, by unregistering mscoree or something along those lines.
OK, so people who need the native .net should use something like winetricks to do the unregistering and installation, right? And eventually mono will be installed automatically like gecko is? - Dan
--- On Tue, 24/8/10, Vincent Povirk <madewokherd(a)gmail.com> wrote:
And eventually mono will be installed automatically like gecko is?
If I ever get the damn thing to build fully on a Linux box, yes.
Is there a problem with that? Mono comes with a script called "build-mingw32.sh" for cross-compiling on linux. I use that for every mono release since about 2.2 as I need a little customization, changing the heap setting, before they get the new garbage collector code scheduled for 2.8(?) ready. I only rebuild the runtime - not the class libraries, so I stop the build in the middle. There are some dependency differences (depending on different versions of dependent dll's) against MSVC builds, file naming differences (the mono dll is called libmono.dll in one but just mono.dll in the other - I filed a bug for it and it is still open), and dependencies on gcc_s*.dll from exception unwinding, but it is basically inter-operable - as I swap one part of the stock msvc build with a custom mingw cross-compiled part for every release for much of the last two years now.
Yes, build-mingw32.sh works, but the resulting build is incomplete. For example, it lacks libgluezilla and a mozilla library to glue to, so the browsing component does not work. This is in the official Windows builds of Mono. I don't know what else is missing. On Tue, Aug 24, 2010 at 12:45 PM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote:
--- On Tue, 24/8/10, Vincent Povirk <madewokherd(a)gmail.com> wrote:
And eventually mono will be installed automatically like gecko is?
If I ever get the damn thing to build fully on a Linux box, yes.
Is there a problem with that? Mono comes with a script called "build-mingw32.sh" for cross-compiling on linux. I use that for every mono release since about 2.2 as I need a little customization, changing the heap setting, before they get the new garbage collector code scheduled for 2.8(?) ready. I only rebuild the runtime - not the class libraries, so I stop the build in the middle.
There are some dependency differences (depending on different versions of dependent dll's) against MSVC builds, file naming differences (the mono dll is called libmono.dll in one but just mono.dll in the other - I filed a bug for it and it is still open), and dependencies on gcc_s*.dll from exception unwinding, but it is basically inter-operable - as I swap one part of the stock msvc build with a custom mingw cross-compiled part for every release for much of the last two years now.
Dan Kegel <dank <at> kegel.com> writes:
What is our intent with adding all these registry keys? It seems as if they are helpful for installing mono, but might get in the way of installing MS .net.
If that's the intent, do y'all want me to make the dotnet20 winetricks verb remove any registry keys that confuse the dotnet20 installer?
I tested dotnet 2.0 and these 2 keys don't harm the installer The only key that causes trouble AFAICT is the already present key [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727] "Version"="2.2.30729" It makes the .NET SP1 installer crash much earlier than it does without this key
participants (5)
-
Alexandre Julliard -
Dan Kegel -
Hin-Tak Leung -
Louis Lenders -
Vincent Povirk