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.
Related
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).
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 am in the process of creating a lightweight application in vb.NET, and was wondering if it is possible to create an application that uses some of the dll's within the .NET 2.0 framework, without actually using the framework itself.
For instance, can I take the dlls from the .NET directory that the app will reference (and only those dlls that it references), put them into a folder inside the app's directory, and then just change the reference path to that new location? That way, when the app is installed on pc's without .net framework installed, the dlls can just be zipped and copied over to the newly installed app directory.
This may all sound a bit confusing, just let me know if you need any more info.
It is quite unlikely that you'll be able to do that.
There is this thing called .net framework client profile for creating lightweight .net apps that do not need the whole framework but you still need to have that installed.
I would recommend using something like Delphi if you need a standalone exe that does not depend on anything.
There is concept of Client Profile in .NET 3.5 and .NET 4.
That is subset of .NET, smallest necessary fraction of .NET that client must have in order to be able to run .NET applications targeting client profile.
There is more detailed overview of the features you may use when targeting client profile.
Unless you move to .Net 4 or above, you need full framework on the client computers. Having said that, which OS are you targeting? Newer MS OS often come with .Net framework installed already.
I have two .NET projects in the same domain. The first project I create long time ago in VB.NET. Now I create another project that I built in C#. How can I set up my new project in the same domain so I can access the new forms that I built in C#. Do I need to submit the whole folder from the project? Do I need to change anything in the web.config? Right now I am getting this error. [PhoneControl] is the new project in C#.
http://www.martinesexpress-inc.com/PhoneControl/Default.aspx
If you look in the error page it says:
alt text http://img246.imageshack.us/img246/5868/capturevv.png
Version Information: Microsoft .NET Framework Version:1.1.4322.2407;
ASP.NET Version:1.1.4322.2407
And you are trying to use some .NET 3.5 components
Change the website to use .Net 2.0 and make sure the server have .NET 3.5 SP1 installed
If you are using IIS6:
alt text http://img185.imageshack.us/img185/1410/capture2s.png
You're declaring the language correctly in your page?
I am building an executable using VS2008 and .NET compact framework 3.5, targetting Windows Mobile 6 professional, but whenever I compile the project, everything that I have specified in the AssemblyInfo.cs file is ignored.
I have done this many times in other projects and it works without problem, but for some reason I cannot get the AssemblyTitle/AssemblyProduct/AssemblyVersion attributes etc to show up (I am trying to view them using Windows Explorer, I am able to see these properties in the details tab for any other assembly that I have built - even other projects in the same solution).
Any suggestions?
That info is looking at the native version info, which on the desktop is set using the AssemblyFileVersionAttribute. The AssemblyFileVersionAttribute is unsupported in the CF, so the only way to set the version info out of the box is to command-line compile. There is a workaround in this blog.
I know this is old, but there's a simpler solution posted here:
Version number in .NET Compact Framework application
You have to use reflection.
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Major System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Minor System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Build System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Revision
in tag PlatformFamilyName; rather that PocketPC, change to add WindowsCE
in csproj