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?
Re: wine.inf: added .NET InstallRoot key
Dan Kegel d...@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 julli...@winehq.org
Re: wine.inf: added .NET InstallRoot key
On Tue, Aug 24, 2010 at 1:52 PM, Alexandre Julliard julli...@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
wine.inf: added .NET InstallRoot key
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
Re: wine.inf: added .NET InstallRoot key
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.
Re: wine.inf: added .NET InstallRoot key
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_le...@yahoo.co.uk wrote: --- On Tue, 24/8/10, Vincent Povirk madewokh...@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.
Re: wine.inf: added .NET InstallRoot key
--- On Tue, 24/8/10, Vincent Povirk madewokh...@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.
