none
Application development in VB.Net without .Net support

    Question

  • Hello,

    I want to develop a program in vb.net that does not require any .Net framework so that it can be run on any machine that does not have .Net installed. Previously we could build such program in Visual Basic 6.0 but now I could not find any option in VB.Net.

    Is this even possible in VB.Net?

    I'm using Visual Studio 2015 for the development.

    Thanks,


    AdNaN


    Friday, April 14, 2017 8:22 AM

Answers

  • Hello,

    VB.NET requires the .NET Framework for applications so what you are after is not possible.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Marked as answer by Adnan Hossain Friday, April 14, 2017 9:06 AM
    Friday, April 14, 2017 8:27 AM
    Moderator

All replies

  • Hello,

    VB.NET requires the .NET Framework for applications so what you are after is not possible.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Marked as answer by Adnan Hossain Friday, April 14, 2017 9:06 AM
    Friday, April 14, 2017 8:27 AM
    Moderator
  • Actually, VB6 did compile to p-code (much like the CLR for .net). However VB6 did have an option to compile to “native” x86 assembly code. However, when choosing “native” compile then while the compiler produced native x86 assembler code, you still needed the VB6 runtime installed on that computer. So the VB6 runtime provided the library code for left$(), mid$() and things like collections etc. and most features of VB6.

    So when you compile VB6 to “native” x86 code, the support library for all those VB6 functions was NOT linked or included in the standalone .exe file. So that native raw x86 code simply made calls to the VB6 runtime for all those VB6 features. It would have been “really cool” to have a linker that pulled in JUST the libraries from that VB6 library code you require into your application. This option of “static linking” was never available for VB6 (it was for c++ applications).


    Of course since about windows 98, the OS shipped with the VB3,4,5,6 runtimes. So you may have been “tricked” into thinking that no support runtime was required, but it was ALWAYS required. (you just after certain time assumed versions of windows had runtime already installed).

    You (still) can create c++ native code with Visual Studio (so this is un-managed code – no .net runtime required). So Visual Studio still does support the creating of .dll’s and library code without the need for any kind of runtime. You are limited to c++ when making this choice. (you can't use c# or vb.net).

    But in the past when creating VB6 or VB.net code? They all DID required a runtime – and most systems today just like VB6 still require a “support” library or so called runtime. Again, even when .net code is pre-compiled as “native code”, the .net runtime library just like VB6 is still required.

    Windows 7 shipped with .net 3.0. Vista with .net 2.0. However due to updates and so much software requiring .net today, then you can be rather assured that you have at least 3.0 runtimes.

    Unless you have a rather specific case, I would write to .net 3.5 or 4 – the vast majority of machines will have such runtimes.

    You can with “relative” ease however create .dll’s with Visual Studio c#/vb.net that can be called by un-managed code. I do this often since I like writing in vb.net, but often need some .dll’s that can be called and consumed by un-managed code. (don’t want to learn c++!). So I often create these “dlls” for office “add-in utility code” to enable VBA to use my .net code. (I thus avoid having to create a COM/ActiveX object in .net)

    So to "interface" with say a communication card, or you needing to interface and write a Remote Desktop channel in VB.net? Well building a channel for remote desktop usally requires in-managed native code. However, that's too much work and being able to write a RDP channel allows me to have the remote application on terminal server launch a LOCAL copy of say outlook for email (and I can send the attachment, and email and message text down the RDP channel). Just grab and install the nu-get package called “unmanaged exports”. The resulting .dll is a standard windows dll with standard “entry” points. (it really a unmanaged wrapper to managed code).

    Keep in mind while the above creates a .dll with standard windows API entry points for un-managed code, the .net runtimes are STILL required. So these “dll’s” are not “com” or “ActiveX” objects, but a simple dll with standard windows API “entry” points that can be used and even linked into non managed code projects. (which in turn will call your CLR .net code).

    So it really depends on what you attempting to accomplish here? Perhaps you have the simple goal of not wanting to worry about some runtime, or perhaps you need to create “dll’s” that can be called and consumed by standard un-managed “native” windows code, but don’t want to learn c++ and continue to using a familiar language like VB6, or in this case vb.net

    If you’re looking to avoid any runtime, then with VB6, or even vb.net that’s not a viable choice. However, you can create un-managed “dll’s” with vb.net (with the above nu-get add in) but at the end of the day, that un-managed dll will in turn call your “managed” vb.net code (and managed code = .net runtime is required in all cases).

    Good luck, and feel free to ask for more details on this issue if need be on your part. Depending on your goal(s), then managed code and Visual Studio + vb.net may well still be a viable choice in your case.


    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Friday, April 14, 2017 5:10 PM