Building RD fails on olewoo

[AndreasMatthias]

Trying to build Rubberduck I get the following error message concerning olewoo:

C:\Users\andreas\Rubberduck\Rubberduck.Deployment\Rubberduck.Deployment.csproj(49,5): error MSB4062: The "RubberduckPreBuildTask" task could not be loaded from the assembly C:\Users\andreas\Rubberduck\Rubberduck.Deployment..\Rubberduck.Deployment.Build\bin\Rubberduck.Deployment.Build.dll. Could not load file or assembly 'olewoo, Version=1.2.6710.37528, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

Any help on this is greatly appreciated.

My build environment:

Microsoft Visual Studio Community 2022 Version 17.1.1 VisualStudio.17.Release/17.1.1+32228.430 Microsoft .NET Framework Version 4.8.04084

[Vogel612]

I can reproduce this on a fresh clone on a machine without MSOffice installation. We should really switch to explicitly referencing this as a nuget package. This seems to be tangentially related to #5969, the base issue seems to be that we're using a positively ancient version of Microsoft.Build.Framework and related.

This should be fixed by pulling the involved dependencies to an up to date version (i.e. 17.2.0 at time of writing) and updating the Rubberduck.Deployment.Build tasks accordingly.

[pflugs30]

I get this error when building a fresh pull of RD next branch in VS2022 with an MSOffice installation. I've also been able to implement all the changes found in PR #5982 on my local machine (since the PR isn't yet merged). However, I can't get past this 'olewoo' error. Here's my version:

The "RubberduckPreBuildTask" task could not be loaded from the assembly C:\dev\personal\Rubberduck\Rubberduck.Deployment..\Rubberduck.Deployment.Build\bin\Rubberduck.Deployment.Build.dll. Could not load file or assembly 'olewoo, Version=1.2.6710.37528, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

One thing I notice: the build doesn't seem to be resolving the relative path correctly (see bolded text). Strangely, even when I hard-code the path to the Rubberduck.Deployment.Build.dll file, the task still fails.

I see the Olewoo folder in the Rubberduck.Deployment.Build project folder, and I've confirmed the RubberduckMeta.sln solution builds. Any other ideas?

[bclothier]

One thing I want to confirm.... is the VS 2022 64-bit? The olewoo reference is a C++ library and it's 32-bit only. Since this was developed, someone made a nuget package for the olewoo (see: https://github.com/leibnitz27/olewoo/pull/16). Now that this exists, it might be possible to use the nuget package instead of hard-coding the olewoo package and dealing with that 32/64 bit due to the C++ interop.

(It might be better even still to get rid of the dependency altogether but that's a whole another thing....)

[pflugs30]

You are right - I'm using VS 2022 64-bit:

VS System Info

### Screenshot  ### All Info ``` Microsoft Visual Studio Community 2022 Version 17.4.3 VisualStudio.17.Release/17.4.3+33205.214 Microsoft .NET Framework Version 4.8.09032 Installed Version: Community ADL Tools Service Provider 1.0 This package contains services used by Data Lake tools ASA Service Provider 1.0 ASP.NET and Web Tools 17.4.326.54890 ASP.NET and Web Tools Azure App Service Tools v3.0.0 17.4.326.54890 Azure App Service Tools v3.0.0 Azure Data Lake Tools for Visual Studio 2.6.5000.0 Microsoft Azure Data Lake Tools for Visual Studio Azure Functions and Web Jobs Tools 17.4.326.54890 Azure Functions and Web Jobs Tools Azure Stream Analytics Tools for Visual Studio 2.6.5000.0 Microsoft Azure Stream Analytics Tools for Visual Studio C# Tools 4.4.0-6.22580.4+d7a61210a88b584ca0827585ec6e871c6b1c5a14 C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used. Common Azure Tools 1.10 Provides common services for use by Azure Mobile Services and Microsoft Azure Tools. Cookiecutter 17.0.22263.6 Provides tools for finding, instantiating and customizing templates in cookiecutter format. Extensibility Message Bus 1.4.1 (main@2ee106a) Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration. Microsoft Azure Hive Query Language Service 2.6.5000.0 Language service for Hive query Microsoft Azure Stream Analytics Language Service 2.6.5000.0 Language service for Azure Stream Analytics Microsoft Azure Tools for Visual Studio 2.9 Support for Azure Cloud Services projects Microsoft JVM Debugger 1.0 Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines Mono Debugging for Visual Studio 17.4.19 (8c0a575) Support for debugging Mono processes with Visual Studio. Node.js Tools 1.5.40817.1 Commit Hash:66443775f9f3b1d8f8fee47af5002828b346688d Adds support for developing and debugging Node.js apps in Visual Studio NuGet Package Manager 6.4.0 NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/ Office Developer Tools for Visual Studio 17.0.32915.00 Microsoft Office Developer Tools for Visual Studio Python - Profiling support 17.0.22263.6 Profiling support for Python projects. Python with Pylance 17.0.22263.6 Provides IntelliSense, projects, templates, debugging, interactive windows, and other support for Python developers. Razor (ASP.NET Core) 17.0.0.2246202+61cc048d36a3fc9246d2f04625988b19a18ab8f0 Provides languages services for ASP.NET Core Razor. SQL Server Data Tools 17.0.62207.28050 Microsoft SQL Server Data Tools ToolWindowHostedEditor 1.0 Hosting json editor into a tool window TypeScript Tools 17.0.10921.2001 TypeScript Tools for Microsoft Visual Studio Visual Basic Tools 4.4.0-6.22580.4+d7a61210a88b584ca0827585ec6e871c6b1c5a14 Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used. Visual F# Tools 17.4.0-beta.22512.4+525d5109e389341bb90b144c24e2ad1ceec91e7b Microsoft Visual F# Tools Visual Studio IntelliCode 2.2 AI-assisted development for Visual Studio. VisualStudio.DeviceLog 1.0 Information about my package VisualStudio.Mac 1.0 Mac Extension for Visual Studio VSPackage Extension 1.0 VSPackage Visual Studio Extension Detailed Info Workflow Manager Tools 1.0 1.0 This package contains the necessary Visual Studio integration components for Workflow Manager. Xamarin 17.4.0.312 (d17-4@be7e8d1) Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android. Xamarin Designer 17.4.0.138 (remotes/origin/d17-4@d36bba3cc9) Visual Studio extension to enable Xamarin Designer tools in Visual Studio. Xamarin.Android SDK 13.1.0.1 (d17-4/13ba222) Xamarin.Android Reference Assemblies and MSBuild support. Mono: a96bde9 Java.Interop: xamarin/java.interop/d17-4@fcc33ce2 SQLite: xamarin/sqlite/3.39.3@23e1ae7 Xamarin.Android Tools: xamarin/xamarin-android-tools/main@0be567a ```

If I'm reading this issue correctly, then neither a Github release nor a NuGet package for Olewoo has been created. I do notice you're a contributor on both projects. Any thoughts or recommendations as to which direction to proceed? :-)

[bclothier]

Indeed, I stand corrected. I thought they had made a nuget package but apparently it never got finished. :(

Just to quickly jerry-rig and verify this is the culprit, can you try and replace the olewoo's DLL with the 64-bit counterparts? olewoo x64.zip

If you can confirm this works, we can look at a more permanent solution to handle both 32-bit and 64-bit VS since the VS build task needs to link to it to run the build task even though the olewoo binaries actually do not get shipped as a part of RD.

[Vogel612]

The build is not actually performed by VS, so the bitness of VS shouldn't matter at all. The relevant bitness is that of MSBuild. There might be a win here by explicitly specifying the PlatformTarget of the meta projects to x86, which would trigger 32-bit linking semantics.

We currently only specify AnyCPU for the Main project and the Test project. Since the meta projects are separate from that we should be able to target that to 32-bit without issue.

[pflugs30]

Thanks for the note, @bclothier. I spent some time last night exploring the Olewoo project and even managed to get it to build after installing numerous tools and extensions. A fun exercise!

I downloaded the zipped file you sent in your comment and used the contents to update the files in (root)\Rubberduck\Rubberduck.Deployment.Build\OleWoo. I then opened and built RubberduckMeta.sln successfully, and then I attempted to build Rubberduck.sln. I then ran into a new error:

Type library exporter encountered an error while processing 'Rubberduck._Extension, Rubberduck'.
Error: Type library exporter encountered an error while processing 'Microsoft.VisualStudio.TextManager.Interop.IVsDropdownBarClient4, Microsoft.VisualStudio.Interop'.
Error: Type library exporter cannot load type 'Microsoft.VisualStudio.TextManager.Interop.IVsDropdownBarClient4' 
(error: Could not load file or assembly 'Microsoft.VisualStudio.Imaging.Interop.14.0.DesignTime, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
The system cannot find the file specified. (Exception from HRESULT: 0x80070002)).

After a bit of Googling, I decided to install Microsoft.VisualStudio.Imaging.Interop.14.0.DesignTime, version 14.0.23205, to the Rubberduck.Deployment project via NuGet. That action resolved the final build error, and the Rubberduck.sln solution builds cleanly!

At this point, I think I'll commit my changes so we can all see where I'm at. While I'm an experienced developer, I'm not that familiar with many of the tools used in this project stack. I welcome feedback on where I'm headed.

[bclothier]

TBH, I'd love to get rid of the Olewoo dependency. As you see, it's a pain to build because of all that C++ stuff involved.

Since the meta projects are separate from that we should be able to target that to 32-bit without issue.

The meta solution has 3 projects; I do not think the 2 projects can be changed (e.g. the code analysis stuff which I assume get hosted by the VS and thus must match in bitness). I'm not confident whether changing the Deployment.Build project only to be 32-bit only will work because we would need to force the VS to run 32-bit MSBuild?

If I am reading this correctly, it sounds like not a feasible solution since VS 2022 now run MSBuild in-process.

I think we need to conditionally redirect the references based on the bitness of VS.

[pflugs30]

Reference #6063. I updated the Olewoo dependencies to the 64-bit versions provided by @bclothier, and the solution built as expected. I created the pull request more to continue the conversation than to initiate the change. I think there are more changes we could make with regards to migrating to NuGet packages rather than embedded references.

At this point, I would like to further contribute to the project. I'm using RD extensively in a legacy Access app I'm maintaining, so I have a vested interest in helping move the project forward.

[pflugs30]

I think we need to conditionally redirect the references based on the bitness of VS.

Would it be easier to simply support VS2022 moving forward? :-) I mean, is there a strong reason not to go that way?

[bclothier]

Unfortunately, no because the whole idea was to avoid restricting potential contributors to a specific VS version that they may not have. Which was actually the original impetus for this whole goldrube machine.

Anyway, can you confirm if the changes made to the PR enable you to build on VS 2022 with 64-bit MSBuild?

[bclothier]

Confirmed as fixed via #6063