In VB.NET, my application is quite simple, and it accesses many images and creates a list with them.
The images are in my application's Resources folder.
The images are accessed in my code where I typed the path, in my PC, how to reach said folder.
Works like a charm, my project displays the images etc.
Now I go to Debug->Build.
Now I go to the bin folder, release folder, and find my application. I upload it.
I share the download to a friend.
My question is, will the images my application should show will appear? Considering the path I created in the code was manually written?
Are the images compiled into your project as "Embedded Resources" or placed in a .resx file? Is the code that you've written accessing them from your project's Resources folder? If so, then everything will work just fine when you copy the application to another computer and run it.
If you're hard-coding a path to your file system, then no; your application won't work on another computer because those files won't be distributed along with the bare executable. There's really no reason to ever do this.
It's difficult to tell from the information provided in your question what exactly you're doing. For more information about embedding resources into your application itself, so all you have to do is distribute the executable, see this simple how-to guide: Using Resources in Visual Studio .NET
Related
I'm working on an application that requires EmguCV. I've gotten EmguCV dlls to load, but I'm stuck on another folder for EmguCV. The x86 folder contains a bunch of vital dlls (such as ffmpeg) and is required. But whenever I load my application, it says it cannot find cvextern (because it's searching in a x86 folder, that isn't there.) I added a folder to my resources with the same name and dlls in it, but it still cannot find it.
I've searched for a long time, with no results.
Is there anyway to embed EmguCV as a resource?
Is it possible to create a VB.Net application which users can just run without installing it first.
If not, is it possible in another .Net language.
If not, how IS it possible :)
PS: The application only has to run under Windows (>= XP).
If they have the .NET Framework installed (the version of it that you developed it), they only need the .exe. You can find the .exe file in the bin directory of your projects folder in your Visual Studio workspace.
If they do not have the framework installed, you'll need to produce an installation for them. It's extremely easy with Visual Studio by just creating a setup project in the same solution as your code.
As long as the user has the .net runtime installed, and your exe has any needed resources in the same folder (dll's, images, ect) theres no problem with that.
If you mean without installing the .net framework though, that won't be possible.
just build the program, and go into the (assuming the project name is app1) app1/app1/bin/debug/ dir. there should be a file there called app1.exe. this file is the compiled .exe from you project. any other computer will be able to run this without doing any installation (provided they have the .NET framework installed (it comes standard on any computer with an os > WinXP))
EDIT: If you were building with debug configuration, it would be app1/app1/bin/debug/, but if you were building with release configuration (which would probably be a better idea if you are distributing) the path would be app1/app1/bin/release/
If you mean running it without the .NET Framework, it used to be possible, but apparently the company's website is no longer in English so I have no idea what's happened to it.
EDIT: If you were building with debug configuration, it would be
app1/app1/bin/debug/, but if you were building with release
configuration (which would probably be a better idea if you are
distributing) the path would be app1/app1/bin/release/
I am developer and have no administration rights to live(production) network.
I had to find away to deploy an app without installation... and my app is self updating this cause other problems too....
The production network Computer check/monitors the file versions etc, so updating in the program files can not be done, where a MSI has been used for deployment.
Using this above I am able to copy and Run the App from the User Profile (where the user has full rights).
lets understand how program runs-
an .exe needs some function which are not inside the .exe, such as , for example substring() function. these predefined function resides in some .dll libraries.
when .exe is executed by user, .exe first finds the .dll and then the function inside that particular .dll.
.exe first looks within the current folder for that .dll
if not found then it searches that in PATHs. (PATH is Environment variable which value is a list of folders such as System32 etc.)
an .exe usually needs only 3 things - .exe itself, .dll which predefined function it is using, and some ActiveX controls(.ocx). apart from these 3, .exe only uses resources (such as icons etc).
lets focus on these 3(.exe, .dll, .ocx)
first you need to check what .dlls your .exe is using. you can easiely do this by using a dependency walker.
then make sure all these .dlls (that dependency walker is showing,or in other words- all these dlls whose functions your .exe needs) are either in current folder(in which your .exe resides) or in the PATHs.
if this step is done then your .exe has high chances to run whithout "installing".
the only problem is that some .dll and all of .ocx, needs to be registered first(means they have to have some kind of registry entry). they are not ready to use just by copying and pasting in current folder or PATHs.
but you can register these .dlls and .ocx's by using regsvr32 (with command line).
after that your .exe should not face any problem to run successfully.
hope you got the main concept.
Questions:
Are XAP files self-contained?
Do they link in all DLLs I have referenced in the project?
If I need to distribute my app, is all I have to do is hand someone the XAP file?
By default, yes. For alternatives, see answer 3.
By default, all except the core DLLs installed by the runtime; it will contain anything from the SDK, Toolkit, 3rd party controls, or your own libraries.
By default, yes. However, there is an option as of Silverlight 3 to package certain assemblies (for example anything from the SDK) into separate ZIP files, which are downloaded separately. In Visual Studio, look in the project properties for a checkbox called "Reduce XAP size by using application library caching." This option toggles whether to create/use the ZIP files or not. Enabling the ZIP option allows multiple Silverlight apps to share the dependency on the ZIP files, so that instead of packaging everything into the XAP every time, you just download the ZIP for one app, and it's saved in the browser cache for other apps.
As for the general contents of the XAP file, there are 2 important bits:
Foo.dll - your project's main assembly (renamed as appropriate)
AppManifest.xaml - describes the requirements for you app, e.g minimum runtime version required, the entry point into Foo.dll, and other settings, including Out-of-browser settings, or whether to use the Library caching feature mentioned above.
Anything else is just content used by your app.
Silverlight XAP files can be tricky if you're using anything other the the core silverlight assemblies (eg. SilverlightToolkit).
XAP files are just zip files - open one up and take a look. They are self contained to the extent that any custom/extra dlls are included - the standard Silverlight assemblies will be installed when a user installs Silverlight.
References to dlls are required in the .proj files for every assembly that will be used. Ie. unlike other project types, if one project references another project, both projects need to reference all dlls used by either project.
You should be able to just hand someone the XAP file if you want - but Silverlight was designed to be used in browsers, so you will need to include the generated test page at least. The best, and most useful, is to provide a publicly accessible web page that hosts your silverlight app.
HTH.
Even though this question is already answered, i'm going to throw this one in too because it hasn't been mentioned yet.
You mention that you are using SL4 - if you are running out of browser (OOB) then you can just ship the XAP file, and use sllauncher.exe (2) to "install" it to the client machine. As part of that install you can also specify where updates are to be sourced from, which is important for when you find bugs or the requirements change.
VB.NET: Can the .EXE built by VS2005 be deployed as a standalone EXE?
When I change the mode in VS2005 to "Release" and build the solution, the bin\Release directory then contains the solution .EXE file, but also a .pdb, vshost.exe and .xml file. What are these extra files and are they necessary?
I copied the .exe file to another machine and it executed properly, but there was a significant delay when it first executed - thereafter it was like any other program. What is the reason for this, and can it be helped? Is it because the other 3 files in the Release folder are not there with it?
The project template that you used to get the project started doesn't have very optimum settings. You'll get the clutter as a result. It is easily fixable. Start with Project + Properties, Compile tab. Make sure the Release build is selected, upper left combo box labeled Configuration.
The .pdb file contains debugging symbols. You don't need it for the Release build although you get slightly more informative exception messages. The stack trace will contain line numbers. You cannot trust them for a Release build though. Click Advanced Compile Options, Generate debug info = None.
The .xml file contains IntelliSense info, it will be generated when you use XML Documentation in your source code. Meant to be used for assemblies that are referenced in another project, quite pointless for an EXE project. Turn off the "Generate XML documentation file" option on the Compile tab.
The .vshost.exe file is a helper process for debugging your app. It hosts a custom version of CLR, configured differently to help with security issues while debugging. It also makes the output of Console.WriteLine() appear in the Visual Studio Output window. There's little point in having it created for the Release build. Select the Debug tab and uncheck the "Enable the Visual Studio hosting process" option.
After making these changes and rebuilding, you should only have the .exe file left in the bin\Release folder.
The slow startup is what's called a "cold start" of the .NET framework assemblies. It is caused by a slow or fragmented hard drive. Since the DLLs were never loaded before, the disk drive needs to dig through the GAC to find the files. You can probably improve it by defragging the disk. Cold starts are never as fast as warm starts though.
A classic trick, used by Microsoft Office and Adobe Acrobat, is to warm up the file system cache by loading their DLLs at login time. They are called "optimizer" in the Startup folder or Run registry key. Very annoying btw, they slow down other programs. You can do the same thing by writing your own little .NET program that doesn't do anything but create a few classes. Put a shortcut to it in the Startup folder.
You should be able to just ship the EXE. The PDB and VSHOST files are used for debugging, you should be able to configure your Release build to not generate these files. You can set this in the 'Advanced Compiler Settings' dialog from the Compile tab in your project properties.
alt text http://philippursglove.com/stackoverflow/compilerdebugoptions.png
(Hat-tip to Amissisco for pointing out it's the same dialog in VS2005/2008.)
I'd imagine the 'significant delay' you experienced when running the program for the first time was due to the .NET Framework being loaded into memory (and probably then paged back out to disk) - unfortunately there's not much getting round that one. You could try throwing hardware at it - memory and a solid-state disk would probably give an appreciable speed increase but may not be a cost-effective option if your application is going to be released on a significant number of PCs. However this should only take place the first time you fire up the application after a machine restart, which is why subsequent launches of your application are quicker.
Only .Exe file is required for deployment. But its better to create a setup. If you are using App.Config file / Application settings, you need to copy the exename.config file too.
Yes, you can deploy it as a standalone EXE, together with any third party DLLs that do not belong to the .NET Framework as well as other resources such as application.config. images and/or other media assets.
The .pdb contains additional symbolic debug info which is not necessary for your application to run. It's meant to assist debugging so that you see your source code instead of assembly code in the debugger.
vshost.exe is used by Visual Studio only, not too sure about the exact purpose of it though.
Whether these three files (.pdb, vshost.exe and the .xml) are present with the .exe should not affect the loading speed of your application. As .NET applications have to be compiled upon first run, the delay that you're experiencing should be partially due to that.
i added itextsharp.dll to my project. it is on my desktop. everything compiles and works fine. if i install my application on another computer it is looking for the same file itextsharp.dll on the users desktop.
how do i make it so that the DLL is built in to the project??
What's with the Desktop now?!
Bundle all your deployable assemblies in the same output folder as your application's main assembly.
While creating the Setup...I am assuming your using MS project setup..make sure all the deployables point to a common folder target.
I don't understand your fixation with Desktop...pls let me know if that is some sort of requirement.
The only thing that is usually deployed onto Desktop is the App's Shortcut.
Make sure that when you add the DLL to your project, you set 'Copy Local' to true. That way, the DLL will get copied to the 'bin' folder of your application rather than the original location of the DLL.