When one user tries to run the application, our ClickOnce application is reporting:
Unable to install or run the application. The application requires stdole Version 7.0.3300.0 in the GAC.
It's interesting to note that the GAC (C:\Windows\assembly) does not have stdole installed in it. How do I get it there?
We are using .NET 3.5, and it has been installed on this computer.
So it turns out that the .NET files were copied to C:\Program Files\Microsoft.NET\Primary Interop Assemblies\. However, they were never registered in the GAC.
I ended up manually dragging the files in C:\Program Files\Microsoft.NET\Primary Interop Assemblies to C:\windows\assembly and the application worked on that problem machine. You could also do this programmatically with Gacutil.
So it seems that something happened to .NET during the install, but this seems to correct the problem. I hope that helps someone else out!
Interesting, I didn't have any references to stdole in my project, but I had a user still receiving the error. I had to add the reference, then change the setting to include. Hopefully that will work.
Well, you can't install to the GAC using ClickOnce. This is documented in this MSDN article.
I my case, I solved this issue going to the Publish tab in the project properties and then select the Application Files button. Then just:
Note: Before you apply this solution, make sure that you have already (as I did), checked all your solution's projects and found no references to stdole.dll assembly.
1 - Located stdole.dll file;
2 - Changed its Publish status to Exclude
3 - After that you need to republish your application.
This issue happened on a Visual Studio 2012, after its migration from Visual Studio 2010.
Hope it helps.
Check if you're really using EnvDTE reference. If not, remove it and recompile.
My solution: I opened the references folder in Solution Explorer (showing all files), and for each assembly that the installation complained about (the name of the assembly may not be exactly the same as the filename of the assembly - within object explorer, but easy enough to figure out), I changed the Copy Local to True. I ended up needing to do that with each Microsoft Office/COM-related assembly.
To H2oRider -- does your application access the Oracle dll in the GAC? What I recommend you do is this: Add the dll to your project and set the build action to "content" and set "copy to output directory" to "copy always".
Then delete your reference(s) to the dll in the GAC. Re-add the reference, but this time drill down to the one you just added to your project.
Now publish it. The application will look for the dll locally, and the dll is included in the deployment so it will find it.
If this doesn't work, then it might be that you can not use that dll if included locally rather than in the GAC. This is true of some assemblies, like the Office PIAs. In that case, the only way to deploy it is to wrap it in a setup & deployment package and use the Bootstrapper Manifest Generator to turn it into a prerequisite you can publish with ClickOnce deployment.
I had the same problem with a ClickOnce deployment.
I solved the problem by going to the 'Publish' tab in the project properties and then selecting the 'Application Files' button.
I then selected the options:
This fixed my problem when I re-published.
I hope this help you :D
Try going to the Publish tab in the project properties and then select the Application Files button. Then set the following properties:
After that you need to republish your application.
If the reference has CopyLocal=true, then the reference will be published with the application. If the reference has CopyLocal=false then the reference will be marked as a prerequisite. This means the assembly must be installed in the client's GAC before the ClickOnce application will install.
There are some assemblies that are installed into the GAC because of the Visual Studio install, not the .NET Framework install. This could be your situation.
We had the same issue with our ClickOnce application that uses Interop with Microsoft Office. It happened only on a few computers in the company.
The best fix we found out was to modify MS Office installation on problematic computers (through the Programs and Features panel) and ensure that ".NET programmability feature" (not sure of the name of the component - our Microsoft_Office versions are not English) was installed for each of the MS Office applications (Excel, Word, Outlook, etc.). This seems to not be included in a default install.
Then the problem with stdole.dll was fixed.
I hope this might help.
Source: Stackoverflow.com