[wix-devs] DUtilUnitTest problem

[Sean Hall]

It's easy to explain where you're supposed to put that kind of code -
src\internal\WixBuildTools.TestSupport (or for C++ code -
src\internal\WixBuildTools.TestSupport.Native).

I don't agree with your analysis though. C++/CLI is not very well supported
by Visual Studio. The IDE will not always report correct information so
unfortunately you can't trust red squiggles. I have never seen any problems
with compiling that code (that code is compiled but not run so it's been
compiling this whole time). We can take your change to make the IDE
experience better (I did something similar for asserting strings are equal
in NativeAssert.h), but I don't expect that to fix the test's flakiness. I
marked it skipped after Jacob and I saw it fail multiple times, but only
intermittently and I don't think we ever saw it fail in CI. I just opened
up the solution in my local branch (without your changes) and saw that
error in the IDE, but it builds fine and the test passes for me.

On Sun, Mar 27, 2022 at 12:39 PM Ron Martin via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> Rob suggested that I send this information to wix-devs because someone
> else (perhaps Sean),might be better
> able to address this issue.
>
> I'm having trouble getting my pull request to fit within the official
> Wix4 build structure.
>
> The scenario is as follows:
>
> The test procedure, DUtilTraceErrorSourceFiltersOnTraceLevel() in
> DUtilUnitTest uses the following code:
>
>     Action^ action = gcnew Action(this, &DUtil::CallDutilTraceErrorSource);
>     Assert::Throws<Exception^>(action);
>
> The Action is expected to throw a .net exception. Xunit exposes
> Assert::Throws<Exception^> for parameters of types with
> type definitions unknown to xunit, substituting the same "unknown" type
> for all of them. In fact, this is the same type as Object.
> The C++ compiler gets confused because it can't tell which overload to
> use, emits *no code at all* and *no error* for this construct.
> The C# compiler ignores the confusing information completely and
> generates reasonable code for this idiom.
>
> I believe that xunit could be modified to not expose such confusing
> information.
>
> I raised this issue on August 13, 2021:
> https://github.com/xunit/xunit/issues/2364.
>
> Meanwhile, back at the ranch, I created my own version of
> Assert::Throws<Exception^>() in a different namespace (not in xunit) in C#.
> I changed the namespace in the original call and, after a lot of messing
> with the build structure, got it all to work. The hard parts involve
> compiling DUtilUnitTest containing a #using to reference my surrogate
> code, getting my new code to build in the right sequence and
> appropriately packaged.
>
> I've published my code in its current incarnation on my github repo
> (cpuwzd) in my DUtilUnitTestBugFix branch.
>
> As is, the code gets a build error due to the build order.
>
> I think that this bug is worth fixing. Ultimately, it needs to be
> properly explained to the xunit people and the C++ people.
>
> Please help.
>
> Thanks.
>
> Ron
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>