[Bug 3972] .NET Framework 2. 0 installation fails on installation of assemblies

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=3972


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net




--- Comment #21 from Anastasius Focht <focht at gmx.net>  2007-11-25 11:56:04 ---
Hello,

--- quote ---
@ Anastasius Focht:

Please note that the trick with the file "l_intl.nls" is not working in all
situations. I assume you are using the win2000 emulation as standard.
When using xp, this file is neither helping not hurting.
--- quote ---

When I post information/howto's/patches I *always* assume standard wine
configuration, e.g. "Windows 2000".
Unless I explicitly state otherwise I don't support other configurations at
this point.

The general rule is: make stuff work for default wine configuration - unless
the installer explicitly requires other OS setting.

Making installers work for all wine OS configurations requires *a lot* of work
and isn't always worth the time.
Why should I open another battlefield, full of XP configuration type
bugs/quirks when the default one can be made to work with considerable amount
of time?

And ... saying "l_intl.nls is a trick" shows a bit of  
floccinaucinihilipilification because you probably don't understand the
technical details behind the installer/.NET at all.

The .NET 2.0 installer currently fails in XP setting due to unsupported
reparse/junction point API. This has nothing to do with casing tables.
Adding a decent implementation of that API just to get the installer work in XP
mode? Waste of time.
If other applications require this API too then it might be worth - but not
now.

--- quote ---
Please also note that the last GIT is also broken as to regards a memory leak.
A memory leak solved at 0.9.49 reappeared in other places in the last GIT. I
would then not assume that it is the best basis for testing. Maybe it's best
waiting for the next stable version.  
--- quote ---

How does the memory leak affect this bug id?
Usually every GIT snapshot and official release contains bugs, regressions and
the like and is sometimes just referred as "broken".
If you ask me personally: you can take several definitions of "stable" but you
hardly will find a version that would meet these standards.
When you track down one bug, you usually unearth a couple of other
bugs/regressions.
Yes, it sucks, but you have to accept this fact.
If you want to wait for a "best basis" version you will probably wait forever
...

Regards


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.