I've read that placing an empty file named <AppName>.exe.local in the application directory will cause the application to look in that directory first for DLLs and OCXs so as to avoid issues with conflicting DLLs and OCXs found elsewhere on the system.
But doesn't the application first look in the application directory anyway? What effect does the .local file actually have?
To be frank, I've never heard of the .local scheme before, but a quick search brought up this article which quite explains it:
For an application foo.exe, if there is a file foo.exe.local exists, Windows will first look at foo.exe’s application directory, before start the regular dll search. To mitigate the COM problem, the redirection applies both to full path dll loading, as well as partial name loading.
It appears that the .local file forces even absolute-path searches to the application directory first, whereas usually absolute paths are unchanged and only relative paths follow the DLL search order.
Applications can depend on a specific
version of a shared DLL and start to
fail if another application is
installed with a newer or older
version of the same DLL. There are two
ways to ensure that your application
uses the correct DLL: DLL redirection
and side-by-side components.
Developers and administrators should
use DLL redirection for existing
applications, because it does not
require any changes to the
application. If you are creating a new
application or updating an application
and want to isolate your application
from potential problems, create a
side-by-side component.
Ref.: Dynamic-Link Library Redirection
Related
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
I have an environment where there is a combination of managed and non-managed executables being run for a particular suite.
I have a scenario where the only reason I have a managed assembly (in this case) is because code was easier to write in C# than in VB6.
My 'main' application, written in VB6, needs to make a call to this assembly. So I create the TLB file, so its COM callable.
Now for deployment, is it better practice to place the managed assembly 'with' the tlb in the windows system directory? to have them both in the same place? Seems to me a bit easier to manage that way.
Or the managed assembly (not-signed since it isn't to be shared among diff apps) should just go to the BIN of the application dir, and the TLB moved to the windows\system32 and registered there.
Overall it seems more straight forward to keep them together, but it doesn't seem to be the correct way to do things.
Thx for any tips.
None of the above. You only need the type library when you compile your VB6 program. It does not need to and should not be deployed on the user's machine. There's a small corner case where a type library can help with marshaling an interface across an apartment or process. That won't be the case in a VB6 app.
Personally, I'd put both of them in your application's installation folder or under the Common Files structure.
The System32 folders are ideally just for the system files. (Ignoring history for the moment :)
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.
We have a Powerbuilder 10 application that is using .Net COM assemblies. We are trying to embed the manifest in the PB application (to invoke COM assemblies without registration). The merged manifest file has added sections for dependecies on the .Net COM assemblies. We have tries various tools to inject the new manifest with different results
- using GenMan32 to inject truncates the application from 6MB to 45KB.
- using ResourceTuner, the file size looks okay, but trying to launch application gives "Fatal Disk Error".
Any suggestions on invoked .Net ComEnabled assembly from PB without registration?
Have you tried it with an external manifest and ensured that works? If an external manifest doesn't work, then the manifest information isn't correct.
Once you have a valid external manifest, you might try the Manifest Tool (MT.EXE) from the .Net SDK. It works well with true EXE files. As Terry noted though, the PB generated executable contains additional information that tools that manipulate the EXE need to respect or they will break it.
http://blogs.msdn.com/patricka/archive/2009/12/09/answers-to-several-application-manifest-mysteries-and-questions.aspx
This is more a redirection than an answer. One thing you need to be aware of is that PowerBuilder produces executables that do not follow standards for Windows executable files. Essentially they are a bootstrap routine to load the PowerBuilder virtual machine, plus a collection of class definitions (objects). The cases you've brought up are not the first I've heard of where utilities meant to modify executables don't work on PowerBuilder executables.
As for a positive contribution on what other directions to follow, I don't really know enough to give qualified advice. If it were me, I'd try to register the COM object if ConnectToNewObject() fails, but I've got no idea if that possible or if that route is a dead end.
Good luck,
Terry.