1

I'm using latest version of VS 2022 preview, and I'm suffering these four compiler errors after using Net Upgrade Assistant to upgrade a .NET 4.8.1 project to .NET 8.0 preview:

BC30002 Type 'Global.Microsoft.VisualBasic.ApplicationServices.ApplicationBase' is not defined.
BC30002 Type 'Global.Microsoft.VisualBasic.ApplicationServices.User' is not defined.
BC30002 Type 'Global.Microsoft.VisualBasic.Devices.Computer' is not defined.
BC30002 Type 'Global.Microsoft.VisualBasic.MyServices.Internal.ContextValue' is not defined.

A more detailed sample of one of these errors:

Severity    Code    Description Project File    Line    Suppression State
Error   BC30002 Type 'Global.Microsoft.VisualBasic.ApplicationServices.ApplicationBase' is not defined. Extensions.Shell32Core  C:\Users\Administrador\Desktop\DevCase\v5.0\Solution\DevCase for .NET Framework\Projects\Extensions\Extensions.Shell32Core\vbc  1   Active

The errors does not point to any line in the source-code files, the "File" column points to "vbc" (vb.net compiler executable).

This is very strange to me.

I thought that maybe it was a external... "special" or auto-generated file which is causing these errors, so I used a third party tool (similar to DnGrep) to search for those namespaces inside all the files, but no plain-text nor binary file in the source-code directory contains any of those four namespaces.

The project that I upgraded is just a dynamic-link library project written in VB.NET, and the contents are very simple with just two modules with few method extensions defined.

I cleaned and tried to rebuild the solution, I also deleted the ".vs" directory, but the errors persists.

Maybe the errors could be related to modules usage or method extensions?, because I upgraded another five VB.NET projects that does not contain modules with method extensions and it worked fine. And all the projects that I upgraded, including this problematic project, all are from the same solution.

Why I'm having those compiler errors and how do I fix them?.

In this zip file you can download and check both the original working project and the problematic upgraded project: https://www.mediafire.com/file/0d7n8g3upf3nt0c/Extensions.Shell32.zip/file

ElektroStudios
  • 19,105
  • 33
  • 200
  • 417
  • Do you have the application framework enabled in the project settings? I'm guessing so. I wonder whether it's related to that. Are you using the `My` namespace anywhere in code? – jmcilhinney Jun 21 '23 at 08:26
  • 'Application Framework' is unchecked by default after the upgrade. I checked it but I get the same error. I'm not using My namespace, but some auto-generated files (Resources.Designer.vb) are using it (and it is not marking any error in the editor). And no problem with the other projects that I upgraded as I said. I edited the post to share a zip file at the end, if you would like to check the project. Thanks for comment. – ElektroStudios Jun 21 '23 at 08:29
  • .NET 8 is .NET *Core* 8, not .NET Framework 4+ 4. The runtime is completely different and a *lot* of legacy code was never ported to .NET Core. Other code doesn't work because it's Windows-specific which makes no sense on a cross-platform environment. Who's `My.User` on Linux? In a container? What's the `Shell` on Linux? Gnome? KDE? – Panagiotis Kanavos Jun 21 '23 at 08:29
  • To use Windows-specific functionality you'd have to target Windows explicitly by targeting `net7.0-windows` or `net8.0-windows`. Some features are available through compatibility packages like [Microsoft.Windows.Compatibility](https://www.nuget.org/packages/Microsoft.Windows.Compatibility/7.0.3) – Panagiotis Kanavos Jun 21 '23 at 08:33
  • 1
    All those `My` methods were convenience functions meant to make migration from VB6 to VB.NET easier. Most of the time they save less than 10 lines of code, but they *do* force you to use possibly outdated implementations. Identity in 2023 is far more complex than the Windows-only model of 2001 for example. – Panagiotis Kanavos Jun 21 '23 at 08:36
  • @Panagiotis Kanavos this does not seem an issue with the source-code at all. I think that I cleared it up it when I described the errors. Targeting windows OS in the project settings still gives the same errors about "vbc.exe". The project that I shared which contains Interop.Shell32.dll reference and method extensions is just a sample, I know that it will only work in windows, but the thing is that any project having modules with method extensions produces these errors when I try to upgrade it to NET 8, at least that is what I'm experiencing. Thanks for comment. – ElektroStudios Jun 21 '23 at 08:37
  • In fact, the compiler errors are still present if I delete the two module source-code files that contains the project. That is, with an "empty" project, I still can't compile it due those errors about vbc. And only happens when upgrading projects having modules with method extensions. This is very strange as I said, don't you think?. What could be happening?. – ElektroStudios Jun 21 '23 at 08:40
  • @Panagiotis Kanavos I'm not using My namespace, I insist. The compiler errors are not pointing to any part of the source-code, I insist. You could always download and check the project from the hyperlink that I shared at the end of the main post. Thanks for comment. – ElektroStudios Jun 21 '23 at 08:44
  • Don't insist. Post the actual code, not links to something that can disappear at any point. The errors say that your code, either directly or indirectly, is using the implementations behind `My`. You haven't posted your `vbproj` but unless you target `net8.0-windows` you're building a *cross-platform* application which can't reference any Windows-specific type. Whatever `Extensions.Shell32Core` is, it sounds like a Windows-specific application – Panagiotis Kanavos Jun 21 '23 at 09:01
  • Perhaps the problem is caused indirectly by one of the libraries used by the project. In Visual Studio you can see all direct and indirect dependencies in the `Dependencies` node. The dependencies can be found in the `obj\project.assets.json` file. You may be able to search for `Global.Microsoft.VisualBasic` to find which packages refer to it indirectly – Panagiotis Kanavos Jun 21 '23 at 09:05
  • Or perhaps the project uses library references. Since .NET Framework 4.5-ish, even Framework libraries were delivered as NuGet packages. A direct DLL reference would cause problems, especially in cross-platform projects – Panagiotis Kanavos Jun 21 '23 at 09:06

1 Answers1

1

I've found an user that suffered the same exact compiler errors, and fortunately a solution is detailed that for the moment is working for me when upgrading this kind of projects that contains modules with method extensions.

The solution is:

Simply put, add the following to your newly created .vbproj-file:

<PropertyGroup>
<MyType>Empty</MyType>
</PropertyGroup>

Place at the end of of .vbproj-file just before end tag.

It seems to be a bug as pointed out by the author of that answer.

ElektroStudios
  • 19,105
  • 33
  • 200
  • 417
  • That's the workaround, not the actual solution. The solution is in the *other* answer - add WinForms support. The question never mentioned this is a WinForms project – Panagiotis Kanavos Jun 21 '23 at 09:08
  • As for the bug, it was fixed 4 years ago in .NET Core 3.1 – Panagiotis Kanavos Jun 21 '23 at 09:10
  • It is not really fixed when after an automated upgrading procedure the project fails to compile with cryptic compiler errors about vbc.exe. And in this case the workaround seems preferable to the solution, since the workaround allows me to maintain cross-platform support for the libraries (not this one, but the others that does not explicitly depends on windows OS and are giving me the same errors) and with the other solution It requires to set "windows" as target OS (additionally to using "true") to avoid the strange compiler errors. – ElektroStudios Jun 21 '23 at 09:15