Buildalyzer icon indicating copy to clipboard operation
Buildalyzer copied to clipboard

ProjectAnalyzer-Building: Cannot find Logger assembly

Open tsuttmann opened this issue 7 years ago • 6 comments

I have an issue similar to https://github.com/daveaglick/Buildalyzer/issues/80. Because of your reply in that issue, i figured out the problem is caused by the generated msbuild argument:

/l:BuildalyzerLogger,"%temp%\JetBrains\bd8b6688-dc19-4a22-a9b4-b9304f556096\a232d1d5-99e0-480f-9b0c-d5f6fab18d57\assembly\dl3\514dd964\00d1471c_7377d401\Buildalyzer.Logger.dll";2324;True. (replaced the actual temp-dir by %temp%)

The dir "00d1471c_7377d401" includes the mentioned dll and a ini-file "__AssemblyInfo__.ini" referencing the Buildalyzer.Logger.dll inside the projects build/debug/ folder, where the dll is alongside the MsBuildPipeLogger.Logger assembly.

The msbuild process is faulted with the message "Could not load file or assembly 'MsBuildPipeLogger.Logger, Version=1.1.2.0, Culture=neutral, PublicKeyToken=null'" (error MSB1021).

I just copied the mentioned MsBuildPipeLogger.Logger.dll from the "build/debug/" folder to "00d1471c_7377d401" dir and rerun the MsBuild process, which then fails with a MSB4016 "Invalid pipe handle." (during the initialisation of ReusableLogger)

If I run the generated msbuild command without the /l argument manually, the process completes successfully.

tsuttmann avatar Nov 26 '18 12:11 tsuttmann

The problem is that the Buildalyzer.Logger.dll is s shadow copy. The dependent dlls aren't copied into the same directory. In consequence the dll resolution of the dependent dlls fails when msbuild tries to load Buildalyzer.Logger.dll.

The quick fix is to turn off shadow copying if possible (e.q. in xunit testprojects by setting shadowCopy to false inside the xunit json-config).

I am not 100% sure but we can possible fix the problem by changing the value of the constructed command slightly. We could inject the codebase instead of the location of BuildalyzerLogger. See ProjectAnalyzer.GetCommand: string loggerPath = typeof(BuildalyzerLogger).Assembly.Location;";

tsuttmann avatar Nov 27 '18 09:11 tsuttmann

Where did daveaglick go?

KCarterSr avatar Nov 27 '18 14:11 KCarterSr

@KCarterSr Lol. It's only been a day.

I probably won't have a chance to dig into too much Buildalyzer stuff until later this week at the earliest. I tend to work my projects in shifts to avoid too much context switching. Once I pick Buildalyzer back up I'll take a look at this and the other outstanding issues. Thanks for the report and diagnosis!

daveaglick avatar Nov 27 '18 14:11 daveaglick

LOL too, you got me. Sorry, I was getting anxious. Actually I meant to put this in #97. I especially should know that programmers have a real life too.

KCarterSr avatar Nov 27 '18 18:11 KCarterSr

I probably won't have a chance to dig into too much Buildalyzer stuff until later this week at the earliest

So that worked out well 😬

Is this still a problem @tsuttmann? In re-reading your issue report, I understand that there's an issue because your application can't find Buildalyzer.Logger.dll, MsBuildPipeLogger.Logger.dll, or both. You're absolutely correct that they're needed - we have to pass Buildalyzer.Logger.dll to MSBuild via the command line and that needs MsBuildPipeLogger.Logger.dll.

Just getting NuGet to pack both was a nightmare. They appear to work okay and get correctly copied/deployed when installing the Buildalyzer NuGet package into a client project. The part I'm getting lost at a bit here is shadow copying. How are you consuming Buildalyzer that's having problems - in a unit test? I'm also not sure how to "turn off" shadow copying as suggested - the assemblies are inside a NuGet package and AFAIK, I don't have control over the specifics of how NuGet unpacks that.

daveaglick avatar May 17 '19 12:05 daveaglick

This problem doesn't seem to be nuget related. I used the resharper test runner to run a xunit project. Without being explicitly disabled, the test runner tends to shadow copy the Buildalyzer.Logger.dll. So my suggestion was to check the Assembly.CodeBase folder first. The documentation for Assembly.Location actually suggests this in the remark section: "To get the location before the file has been shadow-copied, use the CodeBase property.".

Maybe this issue isnt worth investigating any further as shadow copies are not a very common thing. I personally prohibited the shadow copy by explicitly adding a setting.

tsuttmann avatar Jul 11 '19 18:07 tsuttmann

Closing this issue due to lack of activity, if anything new, open a new one.

phmonte avatar Feb 16 '24 20:02 phmonte