I have done over 20 installer classes for MSI's in c#, i'm now attempting one in c++/cli. I add my project output file (which contains my installer class) to the custom actions "Install"... i over ride OnAfterInstall within the Installer Class, with no code at the moment and i get the following error (just testing):
Error 1001. Exception occurred while initializing the installation:
System.10.FileLoadException: Attempt to load an unverifiable executable with fixups (IAT
with more than 2 sections or a TLS section.) (Exception from HRESULT: 0x30131019).
i would appreciate any guidance on this issue... I've never experienced it before. when this error happens it initiates a rollback... below is a link to the MSI LOG:
http://www.evas.com/MSILOG/MSI67b70.LOG
i would greatly appreciate some guidance,
Thank you
I've only written this type of custom actions in C++ so I don't know for sure what is the problem.
I found on MSDN the following samples, maybe it will help you:
http://msdn.microsoft.com/en-us/library/system.configuration.install.installer(v=vs.71).aspx
Related
We have a very old DLL that is no longer supported by a vendor, that we need to try and get working via a new piece of software as part of transitioning away from it. It was written in 2000 (!) and we have a fair bit of documentation for it, telling us that it is an ActiveX iSAEDataObject component and has a number of services within it.
I've googled just about everything I can think of on the topic, and have seen there is a lot of references to making sure it is set to build as x86 (I have); I'm just trying to run it in the simplest of VB console applications to try and interact with it.
It registered successfully using regsvr32, and I can import it as a reference into my solution. From there, there are 5 classes, but two have methods showing underneath them in Object browser, and the other three don't - only New().
But... even if I select one that does have a method and try to run it, it gives me this error:
System.Runtime.InteropServices.COMException: 'Retrieving the COM class factory for component with CLSID {FDF93D0E-1D17-11D4-8F41-00C04F566282} failed due to the following error: 800a801d Exception from HRESULT: 0x800A801D.'
I'm desperate to get this going, and have googled and googled; but can't seem to find much else other than the 32 vs 64 bit info. Any help would be gratefully accepted :)
Have been working on it all day today, and have got a little further. In the Object Explorer within Excel, I can see the methods - so hopefully inching forward; I just need to understand why I can't see them from within the iDE.
I also got rid of an error by downloading and registering MSRDO20.dll; so now am only left with (no doubt the most important!):
Could not determine the dependencies of the COM reference "iSAEDataObject". Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY))
I tried the above solution,but unfortunately there is no difference in behaviour.So kindly suggest how to proceed further.
Regards,
Ranjan VijayKumar.
Well you have a crash of some kind, not a WiX issue. If the install didn't fail, then you just have a crashing app. Tell someone what the exception is, the actual error message. Add some debugging to your program and perhaps try/catch exception handling and tracing to see how far it gets and where it crashes. For debug purposes, have it show a message box as the first thing it does so you can see that it loads and has no missing dependencies. Verify in your code that the things you are doing are actually working etc. I'm guessing it's been voted down most likely because it's not a WiX question at all - it's just your code crashing or a missing dependency for which have supplied no data at all.
See the Wix samples for how to create a shortcut the proper way.
A couple of more links:
Wix Toolset Manual Table of Contents
How To: Files, Shortcuts and Registry
First of all - awesome job on PEX !!!
We are trying to do code explorations for one of our Office Add-In project. So, first of all let me ask yo this - Is this is feasible ? In other words can PEX help me with Add-In/VSTO projects ?
Secondly, I trying to execute PEX on one of our Add-In methods and got the following error
--- Description
runtime context Microsoft.Pex.Engine.Libraries.MicrosoftVisualBasicLibrary+ProjectErrorRuntimeContextAttribute+Context failed to open
runtime context Microsoft.Pex.Engine.Libraries.MicrosoftVisualBasicLibrary+ProjectErrorRuntimeContextAttribute+Context failed to open
--- Exception details
System.InvalidProgramException: Common Language Runtime detected an invalid program. at System.Void Microsoft.VisualBasic.CompilerServices.ProjectData..ctor()
at Microsoft.VisualBasic.CompilerServices.ProjectData Microsoft.VisualBasic.CompilerServices.ProjectData.GetProjectData()
at Microsoft.VisualBasic.ErrObject Microsoft.VisualBasic.Information.Err()
at System.Void Microsoft.VisualBasic.CompilerServices.ProjectData.ClearProjectError()
Any help is appreciated !!!
Thanks,
Mrunal Buch
I saw the same InvalidProgramException issue recently when running Pex. I had been able to run Pex successfully earlier, without any issues. I uninstalled the Windows security update KB2742595 and that fixed the issue. I do not see the InvalidProgramException from CLR any more.
For reference, here is a similar issue with the security update and the MS unit test framework.
I have an application which relies on several libraries built by other people in my organization, one of which has stopped working. I get this error in the command-line:
Unhandled Exception: System.IO.FileLoadException: A procedure imported by 'XXX.dll' could not be loaded.
I opened up Dependency Walker to try and track down the source of the problem, although I should say that I am brand-new to Dependency Walker and I don't really know what I'm doing. Here's what I see in the log window:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Which seems straightforward, except:
Due to my unfamiliarity with DW, I can't seem to find what module this error is actually referring to
The same DLL that ships with old version of the application, which still works, shows the same thing in Dependency Walker
The only difference I can find between the old and new DLL is that KERNEL32.DLL shows up as red in the newer one, and the function K32EnumProcessModules appears as red (not exported). This same function does not appear at all (green or otherwise) for the old DLL.
To summarize so far: one DLL works and the other doesn't; both show up as 'bad' in Dependency Walker, but in only one does the function K32EnumProcessModules appear as no good. I do not know if this function is what is causing the "unresolved import" error and would like to find out.
The only change in the application I have made that I think could've caused this is upgrading the runtime from .NET 2.5 to .NET 4. This upgrade was made for reasons unrelated to this DLL, and should not affect it: the DLL does not make any calls to .NET components higher than 2.5, and other people in my organization using the same library have reported that it works fine with .NET 4.
I realize I'm providing sparse information, mostly because I'm not sure what information will help troubleshoot this problem. Please let me know if there are tests you'd like me to perform to find out more.
Probably releated to this https://blogs.msdn.microsoft.com/vcblog/2009/08/27/windows-sdk-v7-0v7-0a-incompatibility-workaround/
Defining PSAPI_VERSION=1 might help.
I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).