I have been developing an addin and all has been going well during development, and i am now at the point that I wish to create the distributable version of the addin, which is the packed version. The packing seems like it goes ok, however, when I open the packed xll file with Excel I get the following error:
Initialization [Error] External library could not be registered -
Path: packed: : ArgumentOutOfRangeException - Unknown
resource type. Only types 0 (Assembly), 1 (Dna file), 2 (Image) or 3
(Source) are valid. Parameter name: type
Any guidance on this would be greatly appreciated.
Thanks.
Excel-DNA only support the following resource types:
.NET Assembly (.dll)
.dna file
Image
Source code file (.cs, .vb, etc.)
.pdb file
The error you're see seems to be caused by the packing of a file that is not any of the types above.
Or perhaps, the version of ExcelDnaPack.exe you're running is not the same as the ExcelDna.xll that you're running.
How does your .dna file look like and what are the files being packed (and their types)?
Related
I am using the Standalone SDK from ZKTEco for a fingerprint scanner. I need to add some custom functionality.
I've downloaded the SDK along with the Demo project. Now when I try to build the Demo project, I get the following error
"Severity Code Description Project File Line Suppression State
Error CS1061 'CZKEM' does not contain a definition for 'SetUserValidDate'
and no accessible extension method 'SetUserValidDate' accepting a first
argument of type 'CZKEM' could be found (are you missing a using directive
or an assembly reference?)"
I have referenced the zkemkeeper.dll file in my project. I'm using VB 2017 on Windows 10. I've tried to look for Embed Interop Types property but I cannot find it in the properties ofzkemkeeper
How can I solve this issue? Any help would be appreciated.
Thanks
I order to make any project referencing the zkemkeeper compile, you need to register it in the windows system.
You should have received a bat file among the dll files called "Register_SDK" as shown in . This is used to register the zkemkeeper in windows. If not, then you must register it manually.
Please, read these posts:
Post 1
Post 2
There is also a starting guide for newbies already written by another member of this community, it´s written in c#.
Best regards.
I'm very new to OMNeT++ and I'd like to use the serialization-library contained in the boost framework. However, when trying to use it, I get quite many errors such as:
Description Resource Path Location Type
undefined reference to `boost::archive::archive_exception::~archive_exception()'
OmCCN line 36, external location: /home/alexander/UniBE/BT/simulator/boost-compiledLibs
/include/boost/serialization/throw_exception.hpp C/C++ Problem
. I guess the problem is that I didn't yet link the compiled library in OMNeT. I've had a look at the makefile but any changes there are worthless since it is generated automatically by makemake. Furthermore, trying to access the menu item 'makemake' in project > properties > OMNeT++ IDE throws an error (The currently displayed page contains invalid values).
Can anyone give me a hint concerning what the error could cause or how to link the compiled library correctly?
Any hints are very appreciated!
cheers
alex
First you should get the library files.
For example in Ubuntu you should install these two packages: libboost1.46-dev, and libboost-serialization1.46-dev. Header files will be installed in usr/include/boost and library files will be installed in usr/lib.
To link the serialization library to your program:
Right click on your project and click properties. Then go to OMNET++ > Makemake.
find the Link tab, and in the "Additional objects to link with: (wildcards, ..." section, specify the path to your serialization library (say /usr/lib/libboost_serialization-mt.a).
I'm running a 32 bit ver of win7 in a vm. I am trying to reference 5 com dlls (VB6) in my .net project. These dlls (and their dependencies) are registered ok since I can use them natively as they form a part of another app and that app is working fine.
I try to set a reference to any of them directly in vs and I get the error message - Library not registered (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).
However, if I set a reference to another com component (which I don't want to reference but which in turn does reference these libs) I find that the references to these com dlls (which I do want to reference) gets set correctly in vs. I then just need to remove the ref to the unwanted dll and everything seems to be good to go.
If I look at the GUID and version details of one of the successfully referenced component, they appear to be the same as the GUID and version that appears in the caption of the error form, when I unsuccessfully try and set a reference to the same component directly.
BTW I have tried repairing the VS installation to no avail
I was wondering if someone could explain what I am doing wrong.
EDIT: Follow-up following Hans suggestion
So I ran
tlbimp mylib.dll
and it returned a TI1006 error - Output would overwrite the input file. So following suggestions found, I then issued
tlbimp mylib.dll /OUT:interop.mylib.dll
and this then returned the error
TlbImp : warning TI3011 : Type library importer has encountered an interface not derived from IUnknown: '_HiddenInterface'. The interface is skipped.
TlbImp : error TI1033 : Cannot find type 'ADODB._Recordset_Deprecated' in 'ADODB, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. There could be a mismatch between the referenced assembly and the type library.
But I'm not sure if this is a red herring since this lib could be referenced when successfully referencing the different higher level dll. I have tried with a dll which doesn't reference ADODB and that seems to work using tlbimp. So, e.g.
tlbimp myNONADODBlib.dll /OUT:interop.myNONADODBlib.dll
works from the commandline. However
tlbimp myNONADODBlib.dll
still generates the error TI1006 - output file will overwrite input file, and I cannot reference this into my .net project
EDIT:
There seems to be a problem with ADO and Win7 SP1. http://support.microsoft.com/kb/2517589 which would account for the deprecated error message (TI1033) I was getting, but not why VS was failing to create a CCW for the dll I can manually create a CCW via tlbimp.
EDIT (12/03/28 10:40):
So I have rebuilt the com dll with the suggested tlb. I can now successfully run
tlbimp mylib.dll
without getting any error messages and it appears to complete successfully. However, when I try and add a reference to that dll in VS, I still get the same original error message ( Library not registered (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))). I have checked the registry and the registration looks ok i.e. it is pointing to the correct path - I'm wondering if it is a permissions-type issue - but I am running vs as admin.
EDIT (12/03/28 10:15):
So I ended up creating a new completely new vm with the same environment - and it worked ok. So I've no idea what is going on other than some registry corruption perhaps!
Many thx
Simon.
You need to use REGTLIB.exe to register the type library of the DLLs.
Type library registration is separate from component registration - the type library supports the introspection/type explorer functionality, and isn't usually required for running a precompiled application, though it may be required for compilation.
I am trying to get going on using First Data's Global Gateway Web Service API. The first strange thing is that I need to download the wsdl and xsd files to my local machine. Then use the local machine's copy for the service reference. I haven't used many web services, so I figured that was okay.
After adding them and try to compile it I get the following errors:
Warning 1 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: There was a problem loading the XSD documents provided: a reference to a schema element with name 'AVSResponse' and namespace 'http://secure.linkpt.net/fdggwsapi/schemas_us/fdggwsapi' could not be resolved because the element definition could not be found in the schema for targetNamespace 'http://secure.linkpt.net/fdggwsapi/schemas_us/fdggwsapi'. Please check the XSD documents provided and try again.
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://secure.linkpt.net/fdggwsapi/schemas_us/fdggwsapi']/wsdl:portType[#name='FDGGWSApiOrder'] C:\Documents and Settings\user\my documents\visual studio 2010\Projects\sltnProcessCreditCard\ProcessCreditCard\Service References\ServiceReference\Reference.svcmap 1 1 ProcessCreditCard
Warning 2 Custom tool warning: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[#targetNamespace='http://secure.linkpt.net/fdggwsapi/schemas_us/fdggwsapi']/wsdl:portType[#name='FDGGWSApiOrder']
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://secure.linkpt.net/fdggwsapi/schemas_us/fdggwsapi']/wsdl:binding[#name='FDGGWSApiOrderBinding'] C:\Documents and Settings\user\my documents\visual studio 2010\Projects\sltnProcessCreditCard\ProcessCreditCard\Service References\ServiceReference\Reference.svcmap 1 1 ProcessCreditCard
Warning 3 Custom tool warning: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[#targetNamespace='http://secure.linkpt.net/fdggwsapi/schemas_us/fdggwsapi']/wsdl:binding[#name='FDGGWSApiOrderBinding']
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://secure.linkpt.net/fdggwsapi/schemas_us/fdggwsapi']/wsdl:service[#name='FDGGWSApiOrderService']/wsdl:port[#name='FDGGWSApiOrderPort'] C:\Documents and Settings\user\my documents\visual studio 2010\Projects\sltnProcessCreditCard\ProcessCreditCard\Service References\ServiceReference\Reference.svcmap 1 1 ProcessCreditCard
I tried the "Reuse types in referenced assemblies" mentioned in many places and that doesn't fix it. Has anyone come across this error? How did you fix it?
I found this answer that seems to at least let me continue working. In the mean time, I am open for other ideas.
Update: Quoting the answer for ease of finding it:
Try adding it as .NET 2.0 Web Reference.
Go to Add Service Reference, then click the "Advanced" button. Then you're given to option to add it as a .NET 2.0 Web Reference. I did this, and got it to work. I couldn't via the standard "Add Service Reference"
I have to maintain an old VB 6 ActiveX DLL called by another third-party program for which I have no sources. This DLL works and compiles fine against the API of said program for about 6 years and 3 major versions.
But now when I try to compile the DLL against a new major version the mentioned error occurs. It seems the error occurs before "my" code is called so there´s no use debugging or logging. The only remedy was to compile w/o binary compatibility which is no real option. My Google search turned up quite some people with the same problem but no solution.
Does anybody here know how to fix this issue ?
I finally figure out how to diagnose VB6 error 32801 in a systemic way.
My theory is When the VB6 compiler is creating a project or binary compatible library, the compiler decompiles the type information from the referenced library. Error 32801 occurs the source code's type information is not the same as the referenced library.
There is a tool called OLEView. This tool can decompile the COM type information into an IDL text. What I do is decompile the referenced library in to IDL and take the last good build of the failing library. Most times it is a build server version but the build does not work on a developer workstation. Decompile the last good build. Use a text comparison tool, like WINMerge, and find the differences between the type libraries. The differences make it easy to track down the problem.
Depending on the difference will determine how to correct. Mitigation can be done by either correcting the reference DLL, or by source code correction, or source code references.
It sounds like one of the types in the interfaces defined in your new DLL is different from one in the previous DLL. I'm deducing you use types defined in the third party program in your public interfaces of your DLL. It sounds to me like the third party has changed the definition of one of the types but kept the name and GUIDs the same. You could use something like OLE/COM Object viewer to check whether that's true. If it is true then you can complain to the publisher of the 3rd party program. Do you have enough political power to succeed?
Bruce McKinney, the guru who wrote Hardcore Visual Basic 6, ran into the same issue with a structure in a type library, where he changed some of the member types. The only fix he could find was (essentially) to break binary compatibility - and that's after some correspondence with the VB6 compiler team, who he knew fairly well. I don't think anyone else could do better.
There is a discussion about this error on devx.com that seems to indicate that the problem stemmed from Microsoft's Scripting Runtime (scrrun.dll).
FileSystemObject compatibility Unexpected error (32810)
Does your DLL reference that library? If so, can you remove the reference (e.g., replace FileSystemObject functionality with intrinsic VB file handling functions and/or API calls).
Are any of the files associated with the core project being compiled marked as Read-Only (i.e. not checked out of SourceSafe or similar repository)?
*.exp
*.vbw
*.lib
---------------------------
Microsoft Visual Basic
---------------------------
Unexpected error (32810)
---------------------------
OK Помощ
---------------------------
This the message I was getting trying to reference in VBIDE an old OCX that has been recompiled recently.
After somewhat long research the offending lines of code causing this error appeared to be
Property Get MouseActivate() As BookmarkEnum
Just changed this to
Property Get MouseActivate() As Boolean
. . . and the error was gone.
BookmarkEnum is an enum from ADO. Our build server is Server 2003 and my dev machine is Win10. The project references ADO 2.8 but apparently this typelib has some differences on Server 2003 vs Win10