When considering cross-DLL calls, if I guarantee that both DLLs use the same compiler and dynamically link to the (same) run-time libraries, does that mean that things like delete and throw will work correctly across the boundary? If not, is there anything that can make such possible?
Yes, no problem. Do a clean build occasionally to catch circular dependencies.
Related
Specifically, I have a problem with MSB3026 - Could not copy bla-bla-bla to bla-bla-bla. Beginning retry 1 in 1000ms. The process cannot access the file bla-bla-bla because it is being used by another process.
I know why it happens - two different libraries use two different versions of the same dependency, but I cannot fix that right now.
So, I want to tell MSBuild to treat all the warnings, except MSB3026, as errors.
I do not understand if this is possible. Is it?
The answer was provided here - https://github.com/Microsoft/msbuild/issues/3062#issuecomment-439945441 by Rainer Sigwald.
There is the flag /warnasmessage which demotes warnings to simple messages. It has higher priority than /warnaserror, so it is good enough.
To fail on all the warnings, except MSB3026 one would pass this to msbuild /err /nowarn:MSB3026
I just finished skating around that infamous "cannot load main class start" thing, and I got blindsided with a sea of errors:
A friend suggests it might have something to do with com.google, but ultimately can't help me.
I haven't made a single alteration to any of the code so far. Eclipse just started up not being able to run and stayed that way. I think there's a way to fix it but it would require making acute changes at the sight of every single error; work that could be wiped by a cleanup if I'm proved wrong.
Anyone have a clue what the issue is? Thank you for the trouble.
UPDATE: Adding guava as a library relieved the error involving com.google, but threw in a handful of others. This one class file contains 3 of the most common unresolved types I've seen scattered throughout: Logger/LogManagaer, PropertyMap, and CrashReport
Your general problems revolve around not having dependencies in the build path. Eclipse's error messages are pretty clear about this; e.g. if a package name is underlined in red and can't be found, then that means it can't be found, and the obvious solution is to add the library that provides it, so that it can be found.
In virtually all cases here, a Google search for the missing packages and classes will lead you to the packages that contain it.
For each unresolved dependency, find the library, add it to the build path, then move on.
I also suggest consulting the documentation that comes with the source code you are attempting to compile, which often simply lists the dependencies, thus saving you the trouble of hunting them down as you go.
While we could do the internet searches for you and hash this out one step at a time, it's both better and faster for you to do it yourself. Better because if you're messing around with Minecraft source, having at least a basic knowledge of how your tools work is going to help you (I also suggest some of the material at http://docs.oracle.com/javase/tutorial/). Faster because the turnaround time of typing package names into the Google search box is a heck of a lot faster than constantly updating your question here and waiting for replies.
It looks like you are missing the Google Collections package, which now is called Guava.
Download the jar file, and add it as a library.
In my VB .NET project, I have several functions that use unmanaged code from within winusb.dll. I tested the code on some machine which haven't drivers installed at all (winusb) and of course errors appears: "Unable to load winusb.dll...."
Now I don't want to try/catch every function imported since will drop performances (or not?) and instead, I'm thinking to use some check in my component constructor for presence of winusb.dll, raise error event and inhibit all functions until next program start. All functions are pointless without that dll. This is a good approach?
Now how can I check reliable for all platforms (xp, wista,7,8) for presence of that dll?
I need a expert opinion to optimum solve the problem and thanks very much in advance.
If System.IO.File.Exists("C:\Windows\System32\winusb.dll") Then
' go ahead
Else
' abort
End If
A better approach however would be to install the winusb library along with your application. An installer that doesn't install all required libraries is pretty worthless.
I'd like to know if there is a way to mix C# and Obj-C code in one project. Specifically, I'd like to use Cocos2D for my UI in Obj-C and call some MonoTouch C#-Library that does some computations and get some values back. Is there a way to do this? Or maybe the other way around, i. e. building in MonoTouch and calling Cocos2D-functions?
Thanks.
The setup that you describe is possible, but the pipeline is not as smooth as it is when you do your entire project in MonoTouch. This is in fact how we bootstrapped MonoTouch: we took an existing Objective-C sample and we then replaced the bits one by one with managed code.
We dropped those samples as they bitrot.
But you can still get this done, use the mtouch's --xcode command line option to generate a sample program for you, and then copy the bits that you want from the generated template.m into your main.m. Customize the components that you want, and just start the XCode project from there.
During your development cycle, you will continue to use mtouch --xcode
Re: unknown (google):
We actually did this as described.
See this page for a quick start, but the last code segment on that page is wrong, because it's omitting the "--xcode"-parameter.
http://monotouch.net/Documentation/XCode
What you have to do to embed your Mono-EXE/DLL into an Objective-C program is to compile your source with SharpDevelop, then run mtouch with these parameters:
/Developer/MonoTouch/usr/bin/mtouch --linksdkonly --xcode=output_dir MyMonoAssembly.exe
This only works with the full version of MonoTouch. The trial does not allow to use the "--xcode"-argument . The "--linksdkonly"-argument is needed if you want mtouch to keep unreferenced classes in the compiled output, otherwise it strips unused code.
Then mtouch compiles your assembly into native ARM-code (file extension .s) and also generates a XCode template which loads the Mono-Runtime and your code inside the XCode/ObjC-program. You can now use this template right away and include your Obj-C-code or extract the runtime loading code from the "main.m"-file and insert it into your existing XCode-project. If you use an existing project you also have to copy all .exe/.dll/.s files from the xcode-output-dir that mtouch made.
Now you have your Mono-Runtime and assembly loaded in an XCode-project. To communicate with your assembly, you have to use the Mono-Embedding-API (not part of MonoTouch, but Mono). These are C-style API calls. For a good introduction see this page.
Also the Mono-Embedding-API documentation might be helpful.
What you have to do now in your Obj-C-code is to make Embedding-API calls. These steps might involve: Get the application domain, get the assembly, get the image of the assembly, locate the class you want to use, instantiate an object from that class, find methods in class, call methods on object, encapsulate method arguments in C-arrays and pass them to the method-call, get and extract method return values.
There are examples for this on the embedding-api-doc-page above.
You just have to be careful with memory consumption of your library, as the mono runtime takes some memory as well.
So this is the way from Obj-C to C#. If you want to make calls from C#/Mono into your Obj-C-program, you have to use the MonoTouch-bindings, which are described here.
You could also use pure C-method calls from the embedding/P/Invoke-API.
Hope this gets you started.
Over the weekend it emerged that someone has been porting Cocos2D to .NET, so you could also do the whole work on .NET:
http://github.com/city41/CocosNet
Cocos2D started as a Python project, that later got ported to Objective-C, and now there is an active effort to bring it to C#. It is not finished, but the author is accepting patches and might be a better way forward.
Calling Objective-C from MonoTouch definitely looks possible. See the Objective-C selector examples
What library are you calling? Perhaps there's an Objective-C equivalent.
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).