[wix-devs] Just when I thought ...
r.sean.hall at gmail.com
Thu Jul 1 17:04:58 PDT 2021
## 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
> 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
> 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:
> 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?
> WiX Toolset Developer Mailing List provided by FireGiant
More information about the wix-devs