3

For some reasons, I have to convert some projects (VB.NET and C#) to .NET Core.

I've followed info from various sources, from Convert .Net Core to .Net Framework and the Assembly Portability preventively to be conscious about the work to do.

Visual Studio 2019 Intellisense, after the conversion, does not show any alert BUT Visual Basic Projects does not compile.

The Visual Compiler shows the error for the namespaces "Global.Microsoft.VisualBasic.Devices" and "Global.Microsoft.VisualBasic.ApplicationServices" ("Type 'Global.Microsoft...' is not defined").

For each VB project, I have updated Microsoft.VisualBasic package. The current version is now 10.3.0. But the problem still persists.

Every project is targeted to .NET Core 3.1 framework.

What could be the problem?

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
michele74c
  • 63
  • 11

3 Answers3

3

This is the solution to my case: compiling succeded adding

<VBRuntime>Embed</VBRuntime>

to .vbproj file. stackoverflow.com/a/20005217/3185385

michele74c
  • 63
  • 11
1

While the solution posted by @michele74c worked, I was also able to resolve this by removing

<MyType>Console</MyType>

from my .vbproj file.

Rob Platt
  • 13
  • 3
0

That's stuff relating to VB-specific features of the Application Framework and the My namespace. For instance, My.Computer exposes an instance of the Microsoft.VisualBasic.Devices.Computer type. Microsoft.VisualBasic.ApplicationServices relates to things like the shutdown mode that you can set in the project properties and the Startup event that you can handle to act at application startup.

You basically need to make sure none of those things are in use in your app before trying to migrate from .NET Framework to .NET Core. I've never tried it but I would assume that that means disabling the Application Framework and creating your own Main method as an entry point, just as you would in C#, and also replacing any uses of the My namespace with the equivalent .NET Framework types and members, as you would use in C#.

jmcilhinney
  • 50,448
  • 5
  • 26
  • 46
  • So, My.Settings should be replaced, too? – michele74c Jul 04 '20 at 09:27
  • In C# you use `Properties.Settings.Default` instead of `My.Settings` so maybe you need to do the same. Not too sure though. – jmcilhinney Jul 04 '20 at 09:36
  • Hard to try, but must do it. Thank you. – michele74c Jul 04 '20 at 09:40
  • 1
    My.Settings and My.Resources should be OK because they are defined directly in your VB project. The other My.XY types are problematic. It's because they are defined in VB runtime Microsoft.VisualBasic.dll in full .NET. But in the .NET Core implementation, some of them are missing, see https://learn.microsoft.com/en-us/dotnet/core/compatibility/visualbasic – Peter Macej Jul 04 '20 at 10:36
  • 1
    Following my previous comment. The breaking changes in VB runtime: vbNewLine is obsolete, types in Microsoft.VisualBasic.ApplicationServices namespace not available (e.g. My.Application), types in Microsoft.VisualBasic.Devices namespace not available (e.g. My.Computer), types in Microsoft.VisualBasic.MyServices namespace not available – Peter Macej Jul 04 '20 at 10:38
  • BUt all those things will have some equivalent way of doing it in C# - theyre basically just a bunch of helper methods for stuff that exists elsewhere – Caius Jard Jul 04 '20 at 11:57
  • @CaiusJard, that's true. All those methods are just code inside and you can write the same or similar code yourself. That said, not all of them are completely straightforward. For instance, the `My.Computer.FileSystem` stuff doesn't all just invoke methods form `System.IO`. Some of it uses Windows API shell functions to display the same dialogues as File Explorer when performing operations on multiple files. – jmcilhinney Jul 04 '20 at 12:35
  • New info: compiling succeded adding Embed to .vbproj file. https://stackoverflow.com/a/20005217/3185385 – michele74c Jul 21 '20 at 09:46