[wix-devs] Just when I thought ...

[Sean Hall]

>From src\mywix4\src\test\burn\README.md:

---
## Building with local changes

The current build process will poison your NuGet package cache, so you may
have to run the following command to clear it:

> nuget locals all -clear
---

This is a problem that was bad for me in the micro repos, and isn't any
better in the mono repo.

> Why do they have to be publicly defined at all?

wcautil is a library that is used by all the WiX extensions but is also
available for people to write their own native custom actions.

On Thu, Jul 1, 2021 at 6:42 PM Ron Martin via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> Just when I thought I had some significant issues behind me, they seem
> to have popped up again.
>
> Here's the scenario:
>
> I modify a macro in wcautil.h at
> ...\wix4\src\libs\wcautil\WixToolset.WcaUtil\inc\wcautil.h.
>
> The modified macro is referenced by scauser.cpp at
> ...\wix4\src\ext\Util\ca\scauser.cpp during the installation
> of test.msi, which is produced when my test case is run. For this to
> work, the code produced by compiling
> scauser.cpp must be embedded into test.msi.
>
> The procedure that I thought was working involves using build.cmd at
> ...\wix4\build.cmd to rebuild everything.
> Doing so also runs all the test cases, including mine. So far, so good.
>
> I install the version of test.msi that has thus been produced and the
> windows installer log (which I have enabled
> in the registry) indicates that my modification of the macro has had no
> effect.
>
> I open Util.wixext.sln at ...\wix4\src\ext\Util\Util.wixext.sln in
> Visual Studio 2019 and examine scauser.cpp.
> I highlight the problematic macro reference and press F12 to see its
> definition. The tab that opens is associated
> with a path outside my repo:
>
>
> C:\Users\...\.nuget\packages\wixtoolset.wcautil\4.0.0-preview.0\build\native\include\wcautil.h
>
> The Solution Explorer lists this file as an external dependency of the
> utilca project.
>
> There is no legitimate way to modify a published nuget package. I want
> the code in my version of the
> repo to depend on its own copy of the code. If there is a work-around
> for this, I have no idea what it is.
> It might require the creation of local nuget packages, the restructuring
> of project files. or more.
>
> Even if I could make this work, consider the next step: I put in a pull
> request for just source code
> that I've changed, leaving out any behind-the-scenes magic that I might
> have used to make it work
> on my computer. The next developer (or the CI robot) who tries to build
> the develop branch will be right
> back where I am now.
>
> Extensions should not depend unnecessarily on published API's and
> interfaces. I can't imagine a new
> extension depending on the macros I'm trying to change. Why do they have
> to be publicly defined at all?
> If I'm inside the extension making changes and additions, I should be
> able to change these definitions
> when it is appropriate or necessary to do so.
>
> I could add a local header file, defining parallel macros with new names
> and change all the references
> to the original macros to use the new macros. This would leave the
> original macros unreferenced and
> ripe for deletion at the time of the next release, but it would also
> leave sub-optimal macro names that
> could be changed back to the originals in the next release. This might
> be more maintenance debt than
> the project should assume.
>
> I might just try this to see how far I can get. Any thoughts?
>
> Ron
>
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>