I have an issue that ive been batteling with for a day or so now and im wondering if anyone might be able to help:
Im am trying to use the ActiveMQ-NMS to dequeue messages via COM in a C++ application. I have managed to build the source and override the 'ComVisible' flag in order to export all the types in the assembly via RegAsm (i did receive warnings about this and the 'Atomic' class but i dont think this is the issue i am facing at the moment).
As part of the RegAsm i have generated a .tlb file that i use in a #import in the C++ client. However, i then receive various errors whilst compiling. Things like:
error C2146: syntax error : missing ';' before identifier 'Keys'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
Essentially, it looks like things like the ICollectionPtr (and various others) are unavailable. Can anyone help me as to resolving these issues? Essentially im looking to register the .net ActiveMQ-NMS assembly as a COM compliant component and then use it from C++...
Unless there's some other reason to use COM and NMS, why not just use the ActiveMQ-CPP client? Then you can avoid all the complexity of COM. ActiveMQ-CPP is located here:
Related
I am creating a C++/CLI wrapper for native C code that has it's own Object typedef and am receiving the C2872 'Object': ambiguous symbol error when linking. The compiler output is:
1>C:\src\OS_kernel.h(27): error C2872: 'Object': ambiguous symbol
1>C:\src\OS_types.h(261): note: could be 'ObjectStruct *Object'
1>C:\src\OS_kernel.h(27): note: or 'System::Object'
It may be worth mentioning that I am mocking this native C code for the purposes of the C++/CLI wrapper; not sure if that opens up a potential solution that would otherwise not be available if no source code was available. I'm guessing there is a way to specify which definition I want the code to use, but I don't know how to specify that. Is that possible? I want to specify it to use the ObjectStruct *Object.
It would be great if I didn't have to modify the mock code since it could potentially be hundreds or thousands of individual places.
As an aside, I am also receiving this error for other types the native library is using, such as Buffer and Boolean.
OK, since you're getting the error in OS_kernel.h, I'm guessing that's part of the C code you're wrapping.
Obviously, one possible solution is to treat the name Object as a reserved word, and edit your C code to not use it. One could argue that this is the most correct solution, but it may not be possible to do that.
Depending on how you're referencing the C code, it may be reasonable to compile it as C++, and stick it entirely within a namespace. That way, when the C code (now C++ code) uses Object it will see the typedef within its namespace, and you'll have the option to reference either namespace in your code.
The fact that you're getting this error from your library's header file indicates to me that you've got a using namespace System; directive, and that the #include of your library's header files comes after that using directive. Consider removing the using namespace System;, or at least moving it after the #include. This way, you won't get that error in the library's headers, you'll just have to deal with it in your code.
I'm trying to write some code that uses git_diff_perfdata from the Libgit2 library.
git_diff_perfdata s;
However, when compiling on my Mac I get the error:
use of undeclared identifier 'git_diff_perfdata'
My understanding is that Libgit2 is meant to be used exclusively through the inclusion of git2.h. Is that correct?
git_diff_perfdata is defined in sys/diff.h and used in status.h
Should I be including sys/diff.h directly. If so, why? Alternatively, what errors might I be making? Looking at the header code I'm unable to see how sys/diff.h is included through anything that is included by git2.h.
Additionally, from what I can tell git_diff_perfdata isn't meant to be an opaque data type (i.e. only the pointer is defined).
I'm using the code downloaded from:
https://github.com/libgit2/libgit2/archive/v0.26.0.zip
The headers in sys are part of the public API, but they're a bit lower level. You can think of them as internal implementation details that have been made public because they might be useful to application developers. If you want to use them, include them directly.
I've been trying to import DTCoreText.h in a class with both Objective-C and C++ code, but it results in the following cryptic compilation errors:
The code doesn't have syntax errors and works correctly when I use it in classes written exclusively in Objective-C, but if I change their extension to .mm the compilation fails. This indicates that is something related to the C++ compiler, but I'm not sure exactly what.
Does anyone have a clue? Thanks.
This was happening due to the fact that some method signatures had parameters with the name class which is a reserved keyword in C++ and eventually led to the compilation errors I've listed above.
Changing the parameters name fixed it.
Although I love the idea of F# type providers my first serious attempt to use them crashed hard.
I was going to connect to a service (WCF) with WsdlService<"http://someurl/some.svc?wsdl">
It fails epicly with:
The type provider
'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders'
reported an error: tmp6E6C.cs(9409,26): error CS0644:
'System.ComponentModel.PropertyChangedEventHandler' cannot derive from
special class 'System.MulticastDelegate'
c:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll: (Location
of symbol related to previous error)
and a lot of other warnings which probably are not relevant:
tmp6E6C.cs(290,28): warning CS0436: The type
'System.Data.DataRowState' in
'c:\Users\someuser\AppData\Local\Temp\tmp6E6C.cs' conflicts with the
imported type 'System.Data.DataRowState' in
'c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Data.dll'. Using
the type defined in 'c:\Users\someuser\AppData\Local\Temp\tmp6E6C.cs'.
tmp6E6C.cs(9427,17): (Location of symbol related to previous warning)
Is this a known feature ;-) or am I using it wrong?
I unfortunately cannot post the WSDL, and its rather large with a lot of types in it so I must admit I am somewhat lazy and have not trimmed it down either. OTOH if I did know what part of the WSDL was offending or creating this error I would of course have put it here.
To change the WSDL is not an option either, so I am mainly interested in knowing why F# WSDL type providers can not handle this (WCF) WSDL, or what I am doing wrong.
It works excellent when consumed by C# and svcutil.exe from VS2010.
I have tried all the params to the WsdlTypeProvider and they do give the same result (except ForceUpdate of course). Should I be consuming these services in another way with F#?
===============================================================================
Added info (since I am new and didnt want to answer. dont ask why :):
Thank you all answering/commenting.
I did go partly this way may self (manually using svcutil). As I tried to say above, I tried to use svcutil by hand, and it fails when compiling the generated C# code (in a library besides the F#).
That is, I did the following:
1) Create the contract by setting up a reference in VS 2010 GUI. This works as expected
2) Try to create it by using svcutil from cmd-line. Then the compile of that file fails with same error.
As it seems from my point of view what happens in svcutil from cmd-line and what happens when using svcutil (or what is used) from the GUI adding the same service does not generate the code with the same parameters. I guess this is partly controlled by the fact that what I try to consume is a WCF service and not a "clean" WSDL/webservice, and the type provider assumes that I try to use a "clean" webservice.
I did not manage to find any params for svcutil takeing care of this, or any possible combinations of params, not saying that I did try all permutations of combinations, but trying the ones probable based upon (trying to) deep reading the documentation of svcutil (and I am not entirley new at using it from cmd-line).
So far I have concluded that it is some "missing" params to svcutil which causes this, and that the F# type provider is not at fault. I would still very much like to solve it somehow, still using F# type providers, but a fallback is to generate the code by GUI in C# and then reference that part of code in F# again. That is not the elegant solution I was trying to achieve, since I do have a lot of services and I would very much like to create such a nice way of prototyping and testing those services.
Another fallback would of course also give up the whole F# part and just go with some unit-testing etc., but that again is defating the purpose of sneaking in F# and learning at same time ;-)
The WSDL type provider (and a few others) are using SvcUtil in the background to do the heavy lifting. If you open ProcExp of taskmgr or some similar tool, you can see the SvcUtil process getting spawned after pasting the TP code into Visual Studio. With ProcExp at least, you can see the full command line with arguments which was used.
So find out exactly what SvcUtil command line was invoked by the TP for your service, and check if it works outside of the F# environment.
The fact that SvcUtil works from C#/VS 2010 is interesting. I assume if you are using F# TPs you are on VS 2012 right now. If so, the version of SvcUtil itself might be different, which could be related.
The specific error would appear to be the same as explained here, so you might have some incomplete annotations in your service code.
I am not able to leave this issue ...
I have now done the following:
Run svcutil with plain vanilla setting: svcutil http://some.address/some/path.svc
Run with some more setting: svcutil /r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\System.dll" /r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\System.Data.dll" http://some.address/some/path.svc
This does generate the follwowing differences in the C# file (it is present in 1) and not present in 2) obviously):
namespace System.ComponentModel
{
using System;
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
[System.SerializableAttribute()]
public partial class PropertyChangedEventHandler : System.MulticastDelegate
{
public PropertyChangedEventHandler(System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context) :
base(info, context)
{
}
}
}
namespace System.Data
{
using System;
using System.Runtime.Serialization;
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
[System.FlagsAttribute()]
[System.Runtime.Serialization.DataContractAttribute(Name="DataRowState", Namespace="http://schemas.datacontract.org/2004/07/System.Data")]
public enum DataRowState : int
{
[System.Runtime.Serialization.EnumMemberAttribute()]
Detached = 1,
[System.Runtime.Serialization.EnumMemberAttribute()]
Unchanged = 2,
[System.Runtime.Serialization.EnumMemberAttribute()]
Added = 4,
[System.Runtime.Serialization.EnumMemberAttribute()]
Deleted = 8,
[System.Runtime.Serialization.EnumMemberAttribute()]
Modified = 16,
}
}
Which again makes the file compile in 2) and is as expected otherwise.
The somewhat strange part then is: Why isnt System.dll used in F# wsdl providers when running svcutil? System.Data.dll I kind of understand, since that isnt default used when running svcutil (at least according to the documentation).
OTOH I think also that the documentations says that IF the assemblies are in the GAC it should use them. So how do I verify they are there, and/or load them to the assembly if not?
Running gacutil -i System.dll (on version 4.5 of the System.dll) gives:
Failure adding assembly to the cache: An attempt was made to load a
program with an incorrect format.
Is it some 64/32 bit issue? (Im on a 64 bit windows if that does have any relevance)
Or to rephrase the problem: How do I get System.dll and System.Data.dll to part of the references when running svcutil when I cannot add the references directly through the WsdlProvider-part?
Im pretty sure it does not use System.dll since if I add the collectiontype param to wsdlprovider:
WsdlService<"http://some.url/some/path.svc", "c:\\temp\\wsdl\\some.wsdlschema", true, ".", true, true, false, false, "System.Collections.Generic.List'1">
it also complains with the following:
The type provider
'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders'
reported an error: Error: No type could be loaded for the value
System.Collections.Generic.List'1 passed to the /collectionType
option. Ensure that the assembly this type belongs to is specified via
the /reference option.
which should have been available directly if System.dll was referenced (I think).
Any ideas to further investigate or solve this issue?
I have a VB6 program that calls a VB6 DLL which in turn calls another VB6 DLL. When I execute the calling program there is an application error which I am unable to pinpoint so I researched how if it was possible to "see" the error in the dll.
I read Stackoverflow entry question about debugging VB6 dll
and followed the directions of Booji Boy to create a vbg. I also followed his directions and removed the two DLLs from he Reference list. The calling program takes a .txt file as input. When I executed the exe I received this error:
Error Number: 13Description: Type mismatch
The error isn't being generated by the application.
What does this mean? How can I debug this issue?
You must have all the source code for the EXE and the two DLLs. You add all the projects into single group file i.e. the VBG. You must have a reference in the EXE project to the first DLL. I have no idea why you have been told you have to remove them. You must have a reference in the first DLL project to the second DLL project. VB is clever enough to silently replace the DLL reference with the project reference. It is also clever enough to silently replace the project reference with the DLL reference if you remove a DLL project from the project group.
Make sure you have error handling set to "Break on All Errors" or "Break in Class".
The type mismatch error can occur from simple things like assign a non-numeric string to an numeric variable. It gets more complicated if you are passing object references around. If you see this error occurs on something like:
Set myObject = someOtherObject
... and it looks as if they should be the same type, this might get very complicated. But first, I'll let you do the debug.
You can use an open source project made in Visual Basic 6.0. It is called "Debuggy v2".This project has multiple roles:
-debugger
-disassembler
-Windows resource extractor
-file hex editor
-window sniffer
-API spy
all rolled into one. I may be useful for what you need.
When starting to work in a VBG a type mismatch can arise if the library references are inconsistent. One library may be referencing another IN the VBG; a second may be referencing the compiled version. Passing objects between them can result in this error.
Concrete example:
VBG contains code for: A.DLL, B.DLL, C.DLL
A references B in the VBG
C references B which is compiled
Code in A calls code in C passing an object defined by a class in B.
Type mismatch
C should have referenced B in the VBG.