PDA

View Full Version : Upgraded to 2012, wtf is flash10k.ocx doing in my [InstallDir]?



mbaldini
11-07-2011, 02:56 PM
I upgraded from 2009, and had some initial problems that took some time to figure out. But now, when the Installer is run, it is throwing a message that 'flash10k.ocx' cannot be unregistered.

We do not redistribute, use, want, or even like Adobe Flash. And since we are a .NET company, we would never use adobe flash. But somehow, InstallShield is putting this file into our [InstallDir] folder. But the file is not included in the project anywhere. I went through all the components, redistributables, folders, etc. There is not a single place that I can find where Flash is being referenced.

This is going to be rather discouraging to our customer, and especially our prospects.

Any ideas as to how to resolve this?

I searched the forums and only found people intentionally including or looking for flash, so I don't think this has been asked before...

MichaelU
11-07-2011, 04:02 PM
If this file is not part of your project, either as a static or dynamic link, it's probably being included as a detected dependency. If that's the case, you should see a mention of it in the build log or output window. Do you see anything of the sort that might help identify why InstallShield is finding it as a dependency?

mbaldini
11-07-2011, 04:36 PM
Interesting, I have no clue as to why it is auto-detecting these...


Adding file 'Flash10k.ocx' that is a dependency of component 'MyApp.exe'
Adding file 'FlashControlV71.dll' that is a dependency of component 'MyApp.exe'
Adding file 'ShockwaveFlashObjects.dll' that is a dependency of component 'MyApp.exe'

mbaldini
11-07-2011, 04:48 PM
I have changed the .NET Settings '.NET Scan at Build' property from 'Properties and Dependencies' to 'Properties Only', and it looks like that solved the issue.

Thanks for the help. I had not even thought about looking through the build log. I guess that goes to show that I am in need of a nice vacation. :D

MichaelU
11-08-2011, 05:38 PM
It would be interesting to know if any other tools could confirm or deny the .NET dependency that the build found (if they can deny it, we should figure out what's wrong on our end). But I'm glad you have your case working correctly.