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

[Ron Martin]

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