I have a ClickOnce application deployed to a virtual machine, Windows 7 32-bit. This application uses some COM components so to get the application working I have created manifests for both the COM assembly and the the application, i.e.
application1.exe and
application1.exe.manifest
comAssembly1.dll and
comAssembly1.x.manifest
Following information from here.
To ensure the application is working, I have run regsvr32 on the COM assembly and all is OK. I then un-registered the assembly and was hoping that all would continue to work. Sadly, it is not the case.
My first port of call was to check my manifests. These match the article referenced above as well as others I have read. So I wanted to check if the manifest was being loaded. I have Process Monitor running and have put a filter on to show only access of files named "application1.exe.manifest", and I don't see any. Having a bit of a google I don't seem to be able to find anywhere that says when then manifest is loaded or by which process.
Have any of you had this problem before? If so, did you discover the cause?
Or is there some magic switch I need in my ClickOnce manifests to tell it to use a manifest file?
And for my own information, when would you expect to see you applications manifest being accessed?
A separate .manifest file will only be used by Windows if the executable doesn't contain an embedded manifest. Problem is that any C# executable already has one. A simple one that's auto-generated by the compiler, it declares the program compatible with UAC.
Project + Add New Item, pick the Application Manifest File item template. It will open in the editor, showing those UAC entries. Move your reg-free COM manifest entries into this one and deploy your app without the .manifest files.
Related
I have a 32 bit application that uses a DLL built by someone else, lets call it xyz.dll. This DLL has dependencies on few other old DLLs. All dlls are saved in the same folder where my app is located. My app compiles fine but in run time, it throws an error "Could not load file or assembly "xyz.dll" or one of its dependencies. is not a valid Win32 application"
I have 2 workarounds that seems to solve this problem. In first one I moved the DLLs to a separated folder and created a batch file to run the app. The batch file first add the dlls' path to the environment, then call the app. Interestingly if I leave the dlls in the same folder with the app and just add this to the path, it wouldn't work.
The second way also moved dlls to a folder and add this path to user environment variable and run the exe directly. Either one of these solutions requires extra steps which is not ideal for app deployment. I am wondering if there is a better way?
When your dll is in the same folder as the application, it is that dll that the application attempts to load, and this fails, as you said.
When you move the dll to another folder and add the pathname of that folder to the PATH environment variable, the application works. In this case, the application is not attempting to load the dll that you have moved to another folder. If this were the case, it would fail. It must be loading another version of the dll that is in one of the folder paths that are in your PATH environment variable.
Simply use Windows search to find all copies of your dll file on your computer. You will be able to determine where that other dll is.
Issue :
System.IO.FileNotFoundException: Could not load file or assembly
'Renci.SshNet, Version=2014.4.6.0, Culture=neutral,
PublicKeyToken=1cee9f8bde3db106' or one of its dependencies. The
system cannot find the file specified.
The Project is built on .Net Framework 4 which helps to transfer the files from local onto S FTP Server.
The Code works fine on my local machine without any issue,When deployed on the PROD server and run as per scheduled giving the error as mentioned above.
Let me know what exactly causing this issue.
If not installing from the gallery make sure the DLL is not marked as blocked. Windows will mark the zip and every file in it for security reasons and you will have to unblock them
Are you developing windows or web application? If web application, try enabling an option in IIS application pool -> Advanced Settings, "Enable 32 bit application" to true. This might solve your problem.
In case of windows or console application, select the reference Renci.SshNet dll and go to its properties and set "Specific version" to false.
After recently upgrading my .NET connector it gave the same error. I compile and run my app in VS and it works fine guessing because it copies all the MySQL NET assemblies to the exe folder so what I did is copied Renci.SshNet.dll to the directory of my exe and it worked. For some reason adding the path to the path system variable didn't help. Final solution was to remove the NET Connector and use mysqld in batch to do the selects and updates for the app.
Looks like you're missing the Renci.SshNet.dll.
In your project references you can edit the properties of Renci.SshNet. Make sure "Copy Local" ist set to true. It will copy the dll on build to your output directory (should be bin/Release).
I checked prior posts like How do I prevent the app.config from being integrated into a .net Library (dll)
but these did not help me with my situation.
I am having trouble keeping my Outlook addin app.config not compiled into the dll. I assume it's being compiled, as when it first loads I ask the application to show me the path of its configuration file using:
MessageBox.Show(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile.ToString());
This returns a path for a file at
C:\Users\...\AppData\ [random name]\outlookadddin.config
instead of using the app.config which is located in the same folder as the the dll itself.
Can I force configuration manager to refer to the dll in the same folder as the assembly rather than creating one of its own?
UPDATE:
after finding this:
how do I make my application read the application config instead of machine.config?
it seems to partially advance a solution, shortly explained, its a known issue with VSTO being deployed via ClickOnce \ MSI. you need to add |VSTOLOCAL to the registery manifest key path.
Problem im facing now, is that if i install my addin on a Network drive, using |VSTOLOCAL it simply won't load, removing |VSTOLOCAL and it works like a charm. any ideas ?
OK i finally found an answer to this:
it appears since vsto 4.0 - you MUST have |vstolocal at the end of the manifest registry key for it to use the .config file from the folder and not from the cache.
My issue was solved by adding |VSTOLOCAL to the regkey, but since i want the addin dll to be placed on a NETWORK drive, this caused trust issues with outlook, which for some reason appearse to be not supporting network drive-installed addins by default.
These were solved by adding this registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\vsto runtime Setup\v4]
"EnableVSTOLocalUNC"=dword:00000001
Everything works well now.
Thanks everyone.
I am working with developing Windows Service using C#. I want to load CLIPSLIB.dll with Windows Service. First I tried write service as console app in vs2010 placing CLIPSLIB.dll in the project debug folder. It worked fine.
But when I install it and run as Windows Service it throws this exception.
Could not load file or assembly 'Mommosoft.ExpertSystem, Version=0.3.0.2, Culture=neutral, PublicKeyToken=20382083c6694bdc' or one of its dependencies. The system cannot find the file specified.
As I figured out this is happening because Windows Service is unable to load relevant dlls. So whare should I put external dlls to load with Windows Service?
Scott Hanselman has an article that describes how to debug assembly loading errors. the downside to this method is that it requires a registry key change and a reboot in order to emable the fusion loader logging.
That article can be found here:
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx
since you are writing a windows service check that the reference for the assembly refers to the bin directory and not some other path. Otherwise the fusion loader logs will identify where it is trying to load the assembly from.
as to the .dll files add a folder to your project and add the .dll files there, change the build properties from do not copy to copy if newer in order that the .dll files will end up in your build output bin path.
You must rebuild the CLIPSLib solution,
Download all files in this link :
Link: https://svn.code.sf.net/p/clipsnet/code/
2.Open CLIPSLib.sln in CLIPSLib folder
3.Right-click on the solution and select rebuild solution.
4.Go to the CLIPSLib folder your CLIPSLib.dll and CLIPSNet.dll is in ..\ ..\mlplatform\bin floder.
hope this help.
We have an application that we wish to install just a basic shell for. As the users use it, it will download and install the necessary dlls for actions that need to take place (imagine a wizard application scenario with several possible paths). Currently, everything is installed for all possible paths through the shell app.
For about 3 months out of the year, the dlls used for the possible paths go through a high churn rate with updates, so we wish to start ensuring the users have the most recent version of these dlls. The idea is that after all their selections are made, we'd make a web check to see what dlls are required for their selection and check to make sure they have the most recent version of those files.
All of this we have a plan for on how to do it. The problem I'm fighting is what is the most appropriate way to "install" these files. ClickOnce is not an option...too much legacy stuff here. Our app is installed in "Program Files" which obviously has restrictions for writing random files into the program's install folder under Vista and later.
Right now I see the options as the following:
On install mark the install directory as writable for the "Everyone" group. I haven't actually tested to see if this would work yet, or if Vista does something different in this scenario.
Split the download portion out into a second app that we can have prompt for elevated privileges so that it can download and install these files.
I'm leaning towards the second option since that maintains the security aspect of the Program Files folder. Others in the group lean towards the first option because they just don't want to have to worry about things. Or is there some other option I'm missing?
The app is a .NET app, though it has some requirements of third party dlls that are not managed assemblies.
As long as the dlls you want to load are managed, there are several ways to do this.
One way is to designate an Environment.SpecialFolder path such as AppData and dynamically load assemblies into your appdomain from there. RssBandit does this for plugins, there is a special directory that loads dlls and searches for specific interface implementations, loads them into a temporary appdomain, and then calls them from the app. You could take this one step further by using an IoC library like ninject or structuremap.
you could also try MEF, the new extensibility framework coming out in C# 4.
Personally, I like what Firefox/xul apps do. It's a hybrid of your two proposed solutions, I suppose. They have an updater.exe that lives in the install directory. I assume that means that the install directory is made writable during install so that they can run the update application. However, having never deployed a application in this manner, I can't tell you how much of a headache (or not) it is.
An alternative which you haven't mentioned, and may not know about, is using the .Net download cache. When you attempt to load an assembly you can give it a code base to load from. If you set the codebase to a web url (i.e. http://mywebhost/mycoolapp/) .Net will download the assembly from that url if it's not found in the download cache. It will also grab the latest version of the assembly from the web url if there is one.
This approach can be a pain as you'll likely have to deal with CAS security issues if your app needs elevated permissions. However, it is nice not having to write code to download the latest versions of your assemblies for you. If you want more information, I can find some resources and give more detailed examples.
The way I handle it is to have an update.exe installed into program files next to the main .exe file.
Then, on app startup, I have the app download an xml file off of the web and save it in the App Data folder. This file contains the latest versions of the dlls and has a simple Filename, Version structure.
Run through the list of filenames and if you don't have the dll locally or you have an older version, then add the needed dll to an update list.
After you generate your update list. Fire off the Updater.exe with a command line list of the files to be updated. You don't have to write them to program files but I do. On Vista, my updater pops up the UAC prompt correctly (as it should to maintain Program Files' security).
The updater then downloads the files to Program Files and restarts the main app.
One problem with firing off the second app is that you have to give it a manifest with "AsAdministrator" set in it.
This isn't hard to do, but once the updater is done and retriggers the main app, it cannot start the main app with normal privileges. An exe running as administrator can only start other exe's as administrator also, even if "AsInvoker" is set in the manifest. I don't know why you can't restrict it back to normal rights...you can only elevate permissions for some reason...