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

[Bob Arnson]

See also commit 9735af72f3ec4dacd2df3c8c2e9704d148f00a59 from Monday, which solved my big build bother.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Thursday, 1 July, 2021 20:05
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: Re: [wix-devs] Just when I thought ...

>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/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/