Re: Self-contained Executables in VB.Net
Armin Zingler
> In VB6, I used to be able to create a compiled executable which was pretty
> well self-contained. It could be transferred over to another machine
> which
> did not have the VB6 Studio installed.
You had to install the VB runtime once.
> When I upgrade to VB.Net, it appears
> that a host of dll's must accompany any executable I create.
You have to install the .Net Framework once.
> This comes up
> because our IT support people insist on keeping business and technical
> application domains separate with evident difficulties on bridging
> applications.
>
> Is the notion (that the dll's must come with the executable) a
Which dlls are you referring to?
> misunderstanding on my part (possibly an issue of jargon)? Or is it a
> restriction built into VB.Net?
Before writing VB.Net or other Framework based applications, I suggest you
read some basics about the environment that you are moving in and that you
make use of:
http://msdn.microsoft.com/en-us/library/a4t23ktk.aspx
Armin
Jan Hyde
thoughts were released on Mon, 30 Mar 2009 10:30:05 -0700
bearing the following fruit:
>In VB6, I used to be able to create a compiled executable which was pretty
>well self-contained. It could be transferred over to another machine which
>did not have the VB6 Studio installed. When I upgrade to VB.Net, it appears
>that a host of dll's must accompany any executable I create. This comes up
>because our IT support people insist on keeping business and technical
>application domains separate with evident difficulties on bridging
>applications.
>
>Is the notion (that the dll's must come with the executable) a
>misunderstanding on my part (possibly an issue of jargon)? Or is it a
>restriction built into VB.Net?
This was just as true with VB6 as it is with VB.Net
The fact that you could copy your VB6 program to another
computer was just dumb luck. The other computer already had
the other files(s) that it needed to run.
--
Jan Hyde
Herfried K. Wagner [MVP]
>> In VB6, I used to be able to create a compiled executable which was
>> pretty
>> well self-contained. It could be transferred over to another machine
>> which
>> did not have the VB6 Studio installed.
>
> You had to install the VB runtime once.
Most current versions of Windows already include the VB6 runtime. So
installation is only necessary if it was not yet installed on the system.
The same applies to .NET-based applications, with the big difference that
the .NET Framework is a larger package than the VB6 runtime library and some
additional ActiveX controls.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Herfried K. Wagner
> I was able to eliminate the ActiveX references as well as
> Interop.Scripting
> - just by making the evident VB.Net substitutions after the automatic
> upgrade
> of the VB6 project. For some reason, that made it possible for the
> program
> to link to the netframe dll's already on the target machine. Only a couple
> of
> dll's now seem to be missing on the XP (business domain) machine:
> msdis140.dll and Interop.Word.dll. The latter looks to have been created
> on
> my technical PC during the VB6 to VB.Net project upgrade (from MSWORD.olb
> to
> which the VB6 project wasl linked).
For the Word-related issue, just take a look at the Microsoft Office
Developer Center (<URL:http://msdn.microsoft.com/en-us/office/>). You'll
likely have to install the Office PIAs on the target machine.
Also note that your application only runs because an appropriate version of
the .NET Framework is installed on the machine, which cannot be guaranteed
for everyone's PC.
Armin Zingler
> I have some further fiddlihg to do with style and related Word settings,
> the
> methods and properties in Interop.Word.dll being somewhat different from
> what
> appreared in VB6.
Maybe of interest:
http://support.microsoft.com/kb/311452
PIAs:
http://www.microsoft.com/downloads/details.aspx?familyid=C41BD61E-3060-4F71-A6B4-01FEBA508E52&displaylang=en
http://www.microsoft.com/downloads/details.aspx?familyid=3c9a983a-ac14-4125-8ba0-d36d67e0f4ad&displaylang=en
http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&displaylang=en
Armin
tstevens
I tried to link directly to MSWord.olb as the VB6 application had done.
Visual Studio created several dll's, the most important for this application
being Interop.Word.dll
I find that to execute, the dll must accompany the exe generated. I had
rather hoped that the executable would automatically tie into libraries which
go with Word - provided of course that execution was on suitably licensed
machines.
Is there a way that I could avoid this inclusion and make the executable
generated more stand-alone? Perhaps I should add that all people in my
company will have essentially the same business set-up as regards the use of
Microsoft applications as my own so what works for me should work for
everyone else who will use this application. As mentioned earlier, the VB6
executable could link into whatever else it needed.
Tom Stevens
"tstevens" wrote:
> Thanks Armin and Herfried,
>
> This is most helpful.
>
> Tom Stevens