[wix-devs] Pull Request #119

[Sean Hall]

You can see that System.Reflection.Assembly.CodeBase is still implemented
here:
https://github.com/dotnet/runtime/blob/3ae87395f638a533f37b8e3385f6d3f199a72f4f/src/coreclr/System.Private.CoreLib/src/System/Reflection/RuntimeAssembly.cs#L87.
You can see their own code still using CodeBase here:
https://github.com/dotnet/runtime/blob/3ae87395f638a533f37b8e3385f6d3f199a72f4f/src/libraries/Microsoft.Extensions.DependencyModel/src/DependencyContextLoader.cs#L127.
We might have to start ignoring the Obsolete warning, but I don't think
there's any chance that they will start making this unconditionally throw
NotImplementedException. I don't think we're interested in supporting
someone bundling v4 into a .NET Core single-file executable right now, and
that seems to be the only time it would throw an exception.



On Thu, Feb 17, 2022 at 11:18 PM Rob Mensching via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> I left a comment on the pull request. I know that .NET 5 is changing the
> way that you are to find the codebase of an assembly (especially when
> building a single-file executable). However, I don't understand why we have
> to make the change now? Everything seems to be working correctly at the
> time using a solution that is supported for all of our scenarios. What is
> the motivation for this change in WiX v4?
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Ron
> Martin via wix-devs
> Sent: Thursday, February 17, 2022 6:48 PM
> To: Ron Martin <wix-devs at lists.wixtoolset.org>
> Cc: Ron Martin <cpuwzd at comcast.net>
> Subject: [wix-devs] Pull Request #119
>
> Pull Request #119
>
> The issue to which I refer as the CodeBase Issue, has to do with multiple
> places within the Wix 4 product that, for one reason or another, attempt to
> determine the file from which the currently executing code was loaded. One
> of the situations in which this might occur includes a vast number of
> system-level tests with names that begin with "CanBuild". This  can happens
> when the test needs to find wixnative.exe or WixToolset.Sdk.props.  Here,
> we are generally looking at a system that has built the Wix 4 product, but
> there might be scenarios in which these tests might be run during or after
> the installation of Wix 4 on a machine that is, for our purposes, only used
> to create installation packages and never used to build Wix 4, itself.
> Such tests might be run from the command line or from Visual Studio.
>
> Beyond these tests, there might be other scenarios in which the Wix 4
> product wants to know from where it was loaded. There are a couple of
> problems with trying to determine how a particular piece of code got loaded
> into the current process. The current code relies on either on a .NET
> Framework 4.72 API or a .NET Core 3.1 API, neither of which is available in
> .NET Core 5.0 or later. In .NET Core 5.0 and later, you can't depend on
> much that is operating-system dependent.
>
> We need a classification of all the scenarios in which this situation
> arises that recognizes the actual problem that is currently being solved
> (or perhaps just being attacked) by using knowledge of the image source.
> Then we need a way to provide the necessary knowledge where it is needed.
>
> When tests are run from disposable file systems, the actual path to the
> loaded image is typically in the temp directory of the user account running
> the test. This is very different from a non-test situation.
>
> I'm sure that I don't grasp all of the issues involved, but I have been
> looking at this issue (among others) for at least nine months. I think that
> it is time for some guidance from and decision making by those holding the
> keys to the realm.
>
> Ron Martin
> cpuwzd
>
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>