I'm using Emgu.CV which is a C# wrapper for the OpenCV libraries.
I changed the Emgu.CV source to invoke from the latest OpenCV library cv110.dll instead of cv100.dll and now I get this error (where ????? is cv110.dll). I have placed the cv110.dll file in all the same locations as the cv100.dll file however this does not help.
On a broader scale, what is the folder search order when looking for dlls, and are there anyone other reasons for this error.
It seems there is a subtle difference between those two assemblies. Without code its hard to tell, but I suggest you to take a look to this blog, specially this post: http://blogs.msdn.com/suzcook/archive/2003/05/29/57120.aspx and http://blogs.msdn.com/suzcook/archive/2003/08/11/57236.aspx
Suzanne Cooks worked in the fusion/CLR loader, and her blogs has tons of tips and advices for this kind of issues.
Good Luck!
You need VCRT(Visual C run time) 8.0 SP1, available from the following link:
http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en
See this post on Emgu CV discussion forum for more information:
http://www.emgu.com/forum/viewtopic.php?f=7&t=88
Related
This is a follow-up to my post yesterday. To recap, I received this error message when trying to build my project:
FSC: Error FS2024: Static linking may not use assembly that targets
different profile
I consulted some kind people in the F# fpchat.com channel, and one of them suggested that the error could be due to the fact that I did not have Profile 47, because FSharp.Data uses Profile 47. I tried downloading the target pack for Profile 47, but was redirected to the Microsoft homepage instead. I tried the second answer on this SO page, but that did not work either. As of now, I am still unable to acquire Profile 47.
I consulted the FSharp.Data GitHub page, but it is not clear to me why Profile 47 is needed. I use VS2013 compiling to FSharp.Core 4.3.0.0; shouldn't that be sufficient, since the GitHub page lists it as one of the supported platforms?
I have created a new project, re-added all my source files and references, and tried re-building. I have even tried uninstalling and then re-installing Microsoft VS, even though I know it is likely irrelevant.
I think it is most probable that the problem lies with referencing FSharp.Data.TypeProviders. The error message does not appear insofar as I exclude reference to FSharp.Data.TypeProviders. The strangest thing is that I have not changed my references at all over the past week or so, but the error message only appeared yesterday.
So, my questions are:
Is Profile 47 really required? If so, how may I acquire it?
Even if I do acquire Profile 47, wouldn't I still experience trouble building my project, since my other references do not target Profile 47?
Are there any approaches that I may not have considered?
After tearing my hair out trying a variety of suggested solutions I found online, I discovered that the only way to resolve the issue was to change my Target Framework from 4.5 to 4.0, re-install all of my references to ensure compatibility with .NET 4.0, and then re-build my solution. Using .NET 4.0 means that I am no longer able to use Microsoft.Experimental.Collections, since it is compatible only with .NET 4.5. This means that I will have to re-write all of my code that makes use of Microsoft.Experimental.Collections, but I consider that a lesser evil than not being able to build my project at all.
So, to answer my own question mentioned in the title, Profile 47 is not required to use FSharp.Data.TypeProviders. :-)
EDIT:
I have found another solution to my problem. I created a new project (again), migrated all my source files over, re-installed all the DLLs I need, and this time I have no trouble whatsoever building my project. I think Carsten (who wrote the first comment to this answer) is correct in saying that the versions became messed up in the original solution files.
Could somebody please explain what cob32api does?
I have the task of migrating a batch cobol system from 32 bit Windows to 64 bit Linux. A large number of programs call 'cob32api' which belongs to Net Express. The Linux equivalent to Net Express is Server Express, but I'm not at all clear on what this particular call actually does. There don't appear to be any parameters required. Sadly, there are also no comments explaining what it's for.
Naturally I get an error when I try to build:
Load error : file 'cob32api'
error code: 173, pc=0, call=1, seg=0 173
Called program file not found in drive/directory
Can anybody help me out here?
Thanks in advance.
OK, I tracked down a colleague who has worked on this stuff and knew what it meant. The call to cob32api is required so that the cobol program in question, as well as any sub-modules, can call Windows APIs. This explains why the corresponding library (cob32api.dll) has no Linux equivalent.
The simple solution to my problem: Remove the call altogether.
I hope this helps anybody who runs into a similar problem.
Thanks for the comments.
Additional information:
The removal of the "cob32api" call had consequences for the sub-modules I mentioned. Ther were a number of calls of the form
CALL WINAPI "windows-function-name" ...
These resulted in later compile errors and therefore needed to be replaced.
Currently I am trying to use Magma to do matrix operation on GPU, however, I found few documents about it. The only thing I can refer to is its testing program and the online generated document(here), which is not convenient to use. And the user guide seems outdated.
If you look here, getri and potri are supported.
I found great cocoa calendar control at googlecode — http://code.google.com/p/calendarcontrol/ . Looks great , but unfortunately i can't build sources of example project. I've try resolve dependencies problem with amber.framework for several hours, but no success. Does anyone tried this control?
Maybe someone have fully read build&go example?
Please read index poge of the site you put here
Blockquote
CalendarControl is dependent on a framework (AmberKitAdditions) contained inside another one of my projects Amber found at http://code.google.com/p/amber-framework which must be available at compile time.
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).