I'm not new to programming, but am new to Microsoft-centric technologies. In this case, I have downloaded Visual Studio 2019 Community edition and am trying to get some stuff working as a VBA Console application.
Here is the link the the Visual Basic Guide I am using as documentation:
https://opdhsblobprod02.blob.core.windows.net/contents/c6aea4f5457448ee818b7292ba695982/8f8c9552565899a6bd5ea3443dc48752?sv=2015-04-05&sr=b&sig=z6HVPKMrsWrYMl1xp9Pk34R040%2B8A71q3nmRLNTG6lk%3D&st=2019-10-18T21%3A16%3A48Z&se=2019-10-19T21%3A26%3A48Z&sp=r
On Page #1 of that guide is a section titled "Development with My". 'My' can have various pieces, depending on the project type. In this case, my project type is: Console Application (from VS, File -> New -> Project, select: Console App (.NET Core) )
On page 59 of that guide is a table that explicitly shows which different parts of 'My' would be available in different project types. For a Console App, all of My.User, My.Resources, My.Setting should be available (as well as some other things).
Yet within my VBA code, the editor implies that the only part of 'My' available is a My.InternalXmlHelper. (I guess that comes by default - I haven't done anything to explicitly try to add such a thing.)
Obviously, some piece of the puzzle is missing here that enables access to all this wonder 'My' functionality that is described. Anybody know what needs to be done here so that my VS environment knows about My.User (and other stuff)?
Thanks.
.NET Core is a different beast altogether, in addition to the other languages you seem to be mixing together.
Based on this link, VB My namespace support is not a part of core 3.0. I'm not sure if it's in earlier core versions, because I haven't been working with VB in Core.
A large part of what makes Visual Basic special is the Visual Basic Runtime. .NET Core 2 contains only the small part of Visual Basic Runtime that is defined in the Visual Basic Language Specification which was initially designed for interop with phones.
The major effort for Visual Basic 16.0 will be moving the Visual Basic Runtime to .NET Core 3.0 to provide expected features like Mid or the My namespace. This work will probably not be ready for the first preview of .NET Core 3.0 but will appear in a later preview.
I think the guide you are working with is for .NET Framework 4.x and earlier (Core is a different initiative that involves getting .NET to run on multiple Operating Systems, etc.). Try creating a new .NET Framework app. The templates will have (.NET Framework) in the name, e.g., ASP.NET Web Application (.NET Framework).
Related
My understanding is that, starting with ASP.NET Core 3.0, .NET Framework is an unsupported target framework, and thus you can only run on the .NET Core runtime.
If this is the case, what NuGet packages can be imported into an ASP.NET Core 3 app?
I assume that you could reference any package that targets netstandard, but what about packages that only target the full framework (i.e., a legacy package that only targets net45)?
What happens if the package you import references an assembly that's not part of .NET Core—i.e., System.Drawing?
TL;DR: You can still reference (packages which depend upon) .NET Framework assemblies from .NET Core 3 and even .NET 5, but you will receive a runtime error if you call into any code which relies upon APIs or libraries not (yet) supported by .NET Core. You can discover these using Microsoft's .NET Portability Analyzer
Background
First off, you're correct that ASP.NET Core 3.x applications can no longer target the .NET Framework, as announced by Microsoft in 2018. That capability previously allowed ASP.NET Core applications to call into .NET Framework libraries, and thus offered an intermediate solution for web applications migrating to .NET Core.
Note: Since the .NET Framework only runs on Windows machines, writing ASP.NET Core web applications which targeted the .NET Framework implicitly restricted those applications to running on Windows.
Behavior
Even when targeting .NET Core or now .NET 5, however, you're still able to reference .NET Framework packages and assemblies, assuming you're on a Windows machine and have the corresponding .NET Framework installed. The inner workings of this are a bit involved, but the short of it is that .NET Core and .NET 5 will evaluate .NET Framework assembles as though they are .NET Standard assemblies. If the API call is also implemented in the .NET Core runtime, it will work fine—but if the API call is exclusively part of .NET Framework, you'll receive an exception.
Surprise! It's really important to emphasize that this is a runtime exception. You will still be able to reference the .NET Framework assembly, write calls to problematic members, and compile your code without any warnings. But as soon as you call into code dependent on a .NET Framework-specific assembly, you'll receive the runtime exception.
Example
With .NET 3.0, a significant portions of .NET Framework libraries have been ported over to .NET Core. In fact, this includes most of the System.Drawing libraries you referenced as an example—though there are good reasons you may not want to use them. If you dig a bit deeper, however, there are plenty of libraries which remain unsupported. One obvious example is the WebConfigurationManager, which could be used to access configuration settings from web.config files.
.NET Framework Code
So, as an example, let's say you have the following function in a .NET Framework class library, which returns an array of keys from your web.config's <AppSetting>s element:
public static class Configuration
{
public static string[] GetAppSettings() => System.Web.Configuration.WebConfigurationManager.AppSettings.AllKeys;
}
ASP.NET Core Code
And then, in an ASP.NET Core controller, you expose an endpoint to retrieve this data:
public class MyController: Controller
{
public IActionResult ApplicationKeys() => Content(String.Join(", ", Configuration.GetAppSettings()));
}
Exception
In an ASP.NET Core 2.x application targeting the .NET Framework, this will work just fine. In an ASP.NET Core 3.x or ASP.NET Core 5 application, however, you'll receive the following runtime error when you call the /My/ApplicationKeys/ route:
System.TypeLoadException: 'Could not load type 'System.Web.Configuration.WebConfigurationManager' from assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.'
Avoiding Surprises
If you're anything like me, this will make you incredibly nervous. You'd much rather receive design-time errors—or, at least, compile-time warnings—as soon as you attempt to call into a library relying upon unsupported code. Fortunately, Microsoft offers a .NET Portability Analyzer, which is also available as a Visual Studio Extension, for exactly this purpose.
As of .NET 5, there's also a compatibility analyzer built into the SDK which will identify calls that are not supported by the .NET 5 runtime on particular platforms. This requires that target libraries explicitly annotate their types with the [SupportedOSPlatform()] attribute, so you won't get any warnings for legacy .NET Framework types. But this will help identify similar types of compatibility issues for libraries targeting a variety of platforms.
Example
If you run the Portability Analyzer on the above sample code, for example, it will output an Excel spreadsheet identifying that T:System.Web.Configuration.WebConfigurationManager is Not Supported in e.g. .NET Core,Version=v3.1 or .NET Standard + Platform Extensions,Version=v2.0.
Note: Microsoft used to offer an API Analyzer as a NuGet package, which promised to provide design-time analysis in Visual Studio. Unfortunately, the code hasn't been updated in two years, and the latest release is 0.2.12-alpha. In my evaluation, it was not effective at identifying issues.
Sample Project
I've put together a sample project on GitHub which demonstrates the above behavior. It includes the following projects:
ASP.NET Core 2.0 Website targeting .NET Framework 4.8
ASP.NET Core 3.1 Website targeting .NET Core 3.1
.NET Framework class library with calls to the legacy WebConfigurationManager
Both ASP.NET Core websites include two endpoints which call into the same .NET Framework 4.8 class library. The first is a "Hello world" example which will execute fine on both projects, since it relies exclusively on common APIs:
http://localhost:5000/Basic/Index
The second will fail on the ASP.NET Core 3.1 project, since it calls into the legacy WebConfigurationManager API:
http://localhost:5000/Basic/Configuration
Disclaimer: This is a quick and dirty repository that I put together to verify my understanding prior to posting this. If there's interest, I'll tidy it up and document it. For now, however, it may prove useful for those of you who need to see this in action.
Acknowledgments
#Chris Pratt offered an excellent answer covering similar material last year. It's worth reading.
I am creating a Console Application in Visual Basic. I would like to use features like My.Computer.FileSystem like I would in Windows Forms but it is unreferenced in my project.
After a bit of googling, I came across this namespace called Microsoft.VisualBasic.MyServices which appears to contain things like FileSystem which I am unable to access with my Console Application
I have tried referencing a few different libraries that I found in COM Components, but none appear to include MyServices
I know this is possible because I used to be able to do this when I worked with Console Applications a few years ago.
Any help would be appreciated.
Thanks.
I have tested to confirm and, using VS 2019, the My namespace is supported as usual in a VB Console Application project targeting .NET Framework 4.8 but it is not supported in a similar project targeting .NET Core 3.1. I'm not sure what the situation will be in .NET 5 but, for now, stick with .NET Framework or forgo the My namespace.
Our project structure is like,
native.dll :- This contains pure native code written in c\c++.
This native.dll exposes some functions using *def file.
Wrapper Library(wrapper.dll compiled with .Net framework v4.0) :-
In order to use functionality of native.dll, a Wrapper lib(wrapper.dll)
is written in C++\CLI using :clr\oldsyntax. This wrapper has all
code of Interoperability and Marshalling.
Application(Console App v4.0) directly uses wrapper.dll to use functionality provided
by native.dll.
Now this project needs to run in .Net Core. This means we will have an
.Net Core application that will reference wrapper.dll that in turn will refer
native.dll.
I know this will not directly work. But the issue is whether .Net Core(CoreCLR) supports
C++\CLI (clr\oldsyntax) runtime environment ?
If no, what can be the possible solutions to this application work ?
whether .Net Core(CoreCLR) supports C++\CLI (clr\oldsyntax) runtime environment ?
As far as I know there is no plan to support C++/CLI with .NET Core.
If no, what can be the possible solutions to this application work ?
You can (should) provide a C API. Mono e. g. supports P/Invoke and .NET Core also supports P/Invoke (see also this Stack overflow question and this DllMap related ticket).
Update (2022-09-02): This answer is from 2016. See the other answers (e.g., this) for what is possible with recent .Net Core versions.
Officially announced eventually...
(next wish... support linux # .Net 5 ^^)
https://devblogs.microsoft.com/cppblog/the-future-of-cpp-cli-and-dotnet-core-3/
C++/CLI will have full IDE support for targeting .NET Core 3.1 and higher. This support will include projects, IntelliSense, and mixed-mode debugging (IJW) on Windows. We don’t currently have plans for C++/CLI for targeting macOS or Linux. Additionally, compiling with “/clr:pure” and “/clr:safe” won’t be supported for .NET Core.
The first public previews for C++/CLI are right around the corner. Visual Studio 2019 16.4 Preview 1 includes an updated compiler with “/clr:netcore”
Updat: From replied of origin url:
"We are still working on the IDE and MSBuild integration, so I can’t share a sample project quite yet. Once it’s available, likely with 16.4 Preview 2 or 3"
(16.4 Preview1 cannot create C++/CLI with .NetCore project.)
191015
16.4 Preview2 Released.
I'v tried asp.net core 3.1 with c++/CLI dll, it works.
(need set plateform to x64 both asp.net core and c++/CLI dll)
.net Core team will only commit (now?) to supporting C++/CLI for Windows only.
The intention was to deliver it for .net Core 3.0. While I haven't found explicit mention of it yet in the release notes, C++/CLI support was a prerequisite for delivering WPF (windows-only), which is now supported in .net Core 3.0.
Support mixed-mode assemblies on Windows - #18013
This issue (#18013) will track progress toward supporting loading and running
mixed-mode assemblies on CoreCLR. The main goal is to provide support
for WPF and other existing C++/CLI code on .NET Core. Some of the work
will be dependent on updates to the MSVC compiler.
The github issue (#659) mentioned above by #Tomas-Kubes, Will CoreCLR support C++/CLI crossplat? - #659, is about cross-platform C++/CLI.
BTW, I am getting compiler warnings on "clr\oldsyntax" with VS2017/.net-4.7. So this compiler flag is already deprecated.
UPDATE: This isn't coming till .Net Core 3.1
Another potential solution (though obviously quite a difficult task) if you want to stick with C++ (i.e. expose an OO interface to .NET) might be to have a look at CppSharp from the mono project. It is able to expose native C++ code through an automatically generated C# wrapper. It supports Windows, Linux as well as OSX. However, I don't know if the generated code can be compiled to a .NET standard target (didn't try to). I can only suppose it would because the generated code does not use any fancy API (it is basically interop and marshalling code); and, by the way, it is also possible to customize the generation process (although, once again, probably not an easy task).
For those who are looking at this for general .Net Core stuff without specific clr parameters (as this is a high result on google) Microsoft have written a guide on how to port C++/CLI to .Net Core:
https://learn.microsoft.com/en-us/dotnet/core/porting/cpp-cli
Port a C++/CLI project
To port a C++/CLI project to .NET Core, make the following changes to the .vcxproj file. These migration steps differ from the steps needed for other project types because C++/CLI projects don't use SDK-style project files.
Replace <CLRSupport>true</CLRSupport> properties with <CLRSupport>NetCore</CLRSupport>. This property is often in configuration-specific property groups, so you may need to replace it in multiple places.
Replace <TargetFrameworkVersion> properties with <TargetFramework>netcoreapp3.1</TargetFramework>.
Remove any .NET Framework references (like <Reference Include="System" />). .NET Core SDK assemblies are automatically referenced when using <CLRSupport>NetCore</CLRSupport>.
Update API usage in .cpp files, as necessary, to remove APIs unavailable to .NET Core. Because C++/CLI projects tend to be fairly thin interop layers, there are often not many changes needed. You can use the .NET Portability Analyzer to identify unsupported .NET APIs used by C++/CLI binaries just as with purely managed binaries.
Build without MSBuild
It's also possible to build C++/CLI projects without using MSBuild. Follow these steps to build a C++/CLI project for .NET Core directly with cl.exe and link.exe:
When compiling, pass -clr:netcore to cl.exe.
Reference necessary .NET Core reference assemblies.
When linking, provide the .NET Core app host directory as a LibPath (so that ijwhost.lib can be found).
Copy ijwhost.dll (from the .NET Core app host directory) to the project's output directory.
Make sure a runtimeconfig.json file exists for the first component of the application that will run managed code. If the application has a managed entry point, a runtime.config file will be created and copied automatically. If the application has a native entry point, though, you need to create a runtimeconfig.json file for the first C++/CLI library to use the .NET Core runtime.
There are some more nuances but these are the actual steps to port
I have developed a simple form which don't have any .Net requirements but the published forms is not opening in users system and showing message to install .Net framework in users systems.
But this issue is happening with Visual Studio only and if I create the same form in VB6 then the form is working nicely without any .Net installation requirement.
Any suggestion about how to get rid of this .Net installation requirement (in Users Systems) in VS forms?
Both VB6 and VB.NET have prerequisites. It just happens that VB6 is so old that the required prerequisites are already included in all operating systems still in use (Windows NT 4 SP4 and above).
You say that you "don't use any .net related things". That's not true. VB.NET itself is part of the .NET framework, as well as the UI library you use (probably WinForms).
If you need your application to run without prerequisites, you could target an earlier version of the framework: .NET 2.0 is included in Vista and above, .NET 3.5 is included in Windows 7 and above.
The System.Windows.Form object is part of .Net. So is every one of the controls you're using on your form. So, if you develop any kind of form in VS (later than VS 6) you are using the .Net framework whether you realize it or not. In this case, it isn't one of Microsoft's arbitrary requirements.
You should also realize that the VB6 Runtime module has to be installed on the target machine for the VB6 version of your form to work properly, too. So, if it runs fine, it's only because that module happens to already be registered on your target machine. That might not always be the case.
How can I create a VB application in VS2008 without requiring the application be run on a computer with a .NET framework in place?
You can't create a non-managed VB application in VS 2008.
You would have to use C/C++ or go back to VS 6.
You can look at the question below for more information on .NET linkers. That is technically an option, but if I were starting a new application that I didn't want to depend on the .NET framework I would not use a managed language.
Running .net based application without .net framework
You'll need to use a 3rd party .NET linker, Visual Studio itself doesn't support what you're after but a number of tools allow it to be done.
A couple of tools:
Remotesoft Salamander .NET Linker
Xenocode app virtualization
Another, non-VS, option is to use Mono to build a "Bundle" which combines both the runtime and your application into a single executable:
Mono:Runtime - Bundles
You can't. You would need to go back to Visual Studio 6 and create a VB6 app.
You can't. VB is .net based, there isn't a non .net VB anymore.
The best you can do is include the .net redistributable with your application's installation.