Compiling with other files inside

[totoymola]

Hello. I am a new comer and this is my first post.

I have been scripting with AutoIt for a while and I decided to give VB2005 Express a try. AutoIt is said to be a "BASIC-like" scripting language, but they appear to have a lot of differences in my opinion. I feel that VB is more complicated!

I want to include files inside my VB executable, which will be extracted when it runs. In AutoIt, this task can be done by doing this:

FileInstall('C:\MyFile.xyz', 'D:\MyFile.xyz')

This will include the file MyFile.xyz from the C directory in the compiled executable, and it will extract it to the D directory when the executable runs.

How can I do the same task in VB2005 Express?

Thanks!

[sheikh78]

Just include it in your project and use the msi to include it when it installs the executable. If you need info how to do this...post back.

[totoymola]

Just include it in your project and use the msi to include it when it installs the executable. If you need info how to do this...post back.

Hi. Thanks for the reply. Yes I know how to make installers (if thats what you mean when you said "msi"). However, I am just wondering if VB2005 can do the same task. What if I just want to make a small standalone program, and I don't want to make an installer for it? Can I make the compiled VB executable "self-extract" the files?

Thanks!

[gigemboy]

Thats what the MSI file is. A file you run that installs the program and any extra files you add to the project... Its a "Windows Installer Package", that can be double clicked and ran in windows...

[totoymola]

Thats what the MSI file is. A file you run that installs the program and any extra files you add to the project... Its a "Windows Installer Package", that can be double clicked and ran in windows...

Hi. Thanks for the reply. Yes, I know what an MSI is, and I know how to create MSI installers (using InstallShield or Wise). But what I want to know is if VB can be compiled with others files inside the compiled executable, and self-extract those files during runtime, similar to the AutoIt code on my first post.

Thanks.

[jmcilhinney]

You can embed files, amongst other things, in a .NET exeutable as resources. These resources can be extracted at run time and saved to disc if you want. This will work with data files, etc., but obviously you cannot do it with a DLL that the executable is dependant on though.

Having said that, why would you bother? If you want to distribute a multi-file application without creating an installer then just stick in a ZIP file and let the user extract all the files to their desired location. Could Microsoft Word extract all its templates, etc. at run time? Of course it could, but why would it? That would only make the executable larger and less efficient at run time. Word is a word processor and that's the job it does. The installer is what extracts all the files and puts them in the desired place because that's its job. If the application itself could do the job of the installer without penalty then why would installers exist at all?

[jmcilhinney]

OK, that was a slightly hasty post. There are, of course, legitimate reasons for embedding files as resources. If there weren't then the facility probably wouldn't exist. Let's say, for example, that you wanted to include an RTF template from which you would generate mail-outs or reports. You could include the template a a resource and then just extract, modify and save it each time. One advantage of using a resource is that it is guaranteed to be present in its original state no matter what. The disadvantage is that if you wanted to change it you'd have to recompile the executable. if you're talking about a file that your app will rountinely access each and every time it runs then you'd normally use a content file, i.e. not an embedded resource, unless you absolutely needed the security of it not being able to be modified or deleted.

[totoymola]

Having said that, why would you bother? If you want to distribute a multi-file application without creating an installer then just stick in a ZIP file and let the user extract all the files to their desired location. Could Microsoft Word extract all its templates, etc. at run time? Of course it could, but why would it? That would only make the executable larger and less efficient at run time. Word is a word processor and that's the job it does. The installer is what extracts all the files and puts them in the desired place because that's its job. If the application itself could do the job of the installer without penalty then why would installers exist at all?

Hi. Thank you for your brief reply. I completely understand the point of using installers. I do not have anything against creating installers, I actually create MSI installers for my own and I also repackage some native EXE installers to MSI for unattended deployment purposes. Same thing with the ZIP idea that you said. That would be the simplest way of doing it, right. In fact, I can even use some programs such as WinRAR or IExpress to make a self-extracting archive to extract my files and run my executable afterwards. But that defeats my intentions. I just brought up the topic because I want to know how the task is done in VB. I am a beginner, and I am still in my learning stage of VB programming. I am trying to compare VB to the other language that I know (AutoIt), and I am curious if I can do the things I can normally do in AutoIt if I use VB.

You can embed files, amongst other things, in a .NET exeutable as resources. These resources can be extracted at run time and saved to disc if you want. This will work with data files, etc., but obviously you cannot do it with a DLL that the executable is dependant on though.

This is exactly what I am looking for! Could you point me to to right direction on how to do this? And example will greatly help.

Thanks!

[jmcilhinney]

Go to the Resources tab of the project properties, select Files from the first drop down button and then press the Add Resource button.

To extract a resource at run time just use My.Resources.ResourceName where ResourceName is the name you gave it when you created it. If I'm not mistaken text files will be retruned by My.Resources as String objects, while other file types will be returned as Stream objects.

[totoymola]

Go to the Resources tab of the project properties, select Files from the first drop down button and then press the Add Resource button.

To extract a resource at run time just use My.Resources.ResourceName where ResourceName is the name you gave it when you created it. If I'm not mistaken text files will be retruned by My.Resources as String objects, while other file types will be returned as Stream objects.

Great! Thanks for your help. Im going to try it soon. I have a good feeling that this is what I am looking for. Thanks again.

Oh by the way, how can I specify the path to where I want to extract the files?

[jmcilhinney]

Like I said, depending on the file type you will either get a String or a Stream (I think, I've never actually tried myself). Saving to disc is completely separate operation. You would use a StreamWriter or FileStream to write text or binary data to disk, or the IO.File class and My.Computer.FileSystem object both have methods to do it in a single operation.