fix CI build

[DeagleGross]

@mgravell i fixed the build, however tests fail on "interceptsLocation" attribute path comparison:

   Assert.Equal() Failure: Strings differ
                                  ↓ (pos 151)
Expected: ···"ribute("Interceptors\\\\NonConstant.input.c"···
Actual:   ···"ribute("Interceptors/NonConstant.input.cs"···
                                  ↑ (pos 151)

git action runs the test in unix env, and so it uses paths written with /.

Question: do we want to fix the InterceptsLocation path generation to include both windows and unix paths? i.e.:

    [global::System.Runtime.CompilerServices.InterceptsLocationAttribute("Accessors\\Data\\Accessor.input.cs", 10, 26)]
    [global::System.Runtime.CompilerServices.InterceptsLocationAttribute("Accessors/Data/Accessor.input.cs", 10, 26)] // new line
    internal static global::Dapper.ObjectAccessor<global::Foo.Customer> Forwarded0(global::Foo.Customer obj, global::Dapper.TypeAccessor<global::Foo.Customer>? accessor)
        => ...

UPD: my bad - interceptors location is generated, so no issue here. I think it makes sense to switch the build to use windows container - let me try it

still maybe that can make sense, if people develop on windows machine, but run on unix or whatever combination we can imagine.

[mgravell]

Question: do we want to fix the InterceptsLocation path generation to include both windows and unix paths?

If we have two, I suspect it'll complain or fail somehow. We could see what happens if we always emit one or the other (meaning: change the path during emit to normalize), but: literally no idea whether the build will be happy with that. I'm guessing *nix style is the best thing to try. I'll give it a go later.

[DeagleGross]

thanks Marc! I guess we can merge this RP to make build go green in following PRs, if you are fine with that