I'm trying to get a Mono development environment set up on a Windows box. Basic install was dead simple, but I'd like to get the VB.NET compiler set up. Only problem is, there doesn't seem to be an installer for it. The official page on VB.NET support implies that there should be, but there isn't; it hasn't been incorporated into the main installer, either. I can download the source package from the mono-basic Github, but since the compiler is self-hosting, that just leaves me in a catch-22 situation where I need the compiler to compile the compiler... :/ On top of which, it doesn't look like the compiler code has been touched in a couple years...is this still supported? Is there any way to get it set up apart from doing a build from source on a machine with the official VS toolchain (or a Linux box with the package installed from a repository) and then copying it over?
Related
So I saw this project http://mxe.cc/ and tried it, it seems like it is very easy to compile stuff for windows with this. I tried to hack it a little bit to compile binaries for linux instead, because, if it compiles for other system so easily how can it be hard to compile for host? 90% of the stuff seems to just build out of the box, but there are some errors and therefore I cannot build. I want to ask, how correctly should I configure mxe to build for the linux host? I know this is not supported but I don't think it should be that hard because we build from source anyway. And there are next to no modifications for downloaded sources too (in a windows build that is).
For people who might ask why I don't want to use shared stuff, I want to basically have two options:
dpkg package for user with dependencies specified (the linux way)
single standalone static executable
Any suggestions? Or maybe there's whole another guide on linux on how to build things from scratch (without a lot of manual work like mxe does)?
I am developing in DX 10/11, & when I tried the code on another computer with a NV 660, it said that d3dx11d_43 was not found. I reinstalled the Visual C++ 2012 32/64 bit & DirectX Runtime, but still says that. I think that the user needs to install the SDK or something.
I get the warning that the debug info cant be found.
From what I have reading, it is because I have something that depends on something debug related. No idea what though.
Is there a way to make the game compile with most, if not all, of the DLLs? I dont mind the extra size. The content of many games out-weigh the extra DLLs that are used.
I did compile as Release.
Edit:
Removed 1st question, since no one answered it.
You can add the dlls you need to the resource file, then compile the resource file to your exe file, and at last, parse the resource file at run time to get the dlls you need. here is a similar question, you can take a look.
d3dx11d_43 is a debug version of d3dx11_43 which your program links with when you do a debug build rather than a release build. The debug version is not included in the directx runtime installer, only in the SDK.
The license does not allow you to distribute it either.
You should build and distribute release versions of the code, or else require users to install the SDK which probably wouldn't be so popular!
Here is my situation. I am on a Mac using Brew as my package manager. I had mono installed on my machine and I was doing all sorts of development in C#. I was doing web development, gui development, ect. When I tried to update my machine using Brew, I got an error. Uninstalling Mono solved the issue.
So, what I did is I toyed around and I created a 2nd user on my machine. Now, this user doesn't need anything to work. I just need Mono and Mono Develop to work on this user without installing anything globally. Everything needs to be installed locally.
So to be specific, I am the only on who uses my machine. My /Users directory looks like this.
/Users/dillon
/Users/dummy
So if I could install mono, in let's say:
/Users/dummy/.mono
Then in my .profile:
export MONO_PATH=/Users/dummy/.mono
Obviously this isn't a perfect world but I was wondering if anyone is an expert on this subject?
(Also, I use this dummy user for other stuff, I use it for Wine and I have a collection of software from school on this user.)
You need to build Mono from source to install it into a custom location (in which case you can install it anywhere you like).
You can install MonoDevelop.app anywhere, but getting it to use your custom Mono is a bit trickier. You might be able to make it work by mucking around with the relevant environment variables though.
How to install Mono in a custom location and the relevant environment variables is all covered here: http://mono-project.com/Parallel_Mono_Environments
A friend sent me 4 files (two .m files, one .pch file, and one .h file) that he says compile together into an Objective-C program. From what I understand, it's an Apple language, and I use Windows. I've been trying to compile it in a new project on Dev-C++, but haven't had any luck. After some research, I downloaded a special Objective-C library for it and selected "Yes" under "Link an Objective C program," but am getting a build error when I try to compile it.
The code uses Cocoa, but according to my friend, it will work the same in Windows if I import Foundation.h instead of Cocoa.h. I found a tutorial on how to compile Objective-C programs in Windows here, but I don't understand step 2 (which is "Set environment variable for GCC compiler (C:\GNUstep\mingw\bin\gcc.exe)") since that file doesn't exist on my computer. When I follow the compilation instructions, I get this error: sh: gcc: command not found. If possible, I'd rather compile it in a GUI-based compiler, as I hate working with command prompts.
Any help with compiling these files on any program is greatly appreciated!
Time to cowboy up, and learn some command line compiling.
First, you need to install the GNUStep on your machine.
Then, set the appropriate environment variable to point to whereever you installed GNUStep to.
Now you should be able to finish the tutorial.
GNUStep is designed to let developers build cocoa applications on a variety of platforms.
Environment variables are named strings that exist for all processes in Windows. If you open a cmd window and enter the command SET you will see a list of all the currently defined environment variables.
On Windows XP, add a new one by right clicking My Computer and selecting properties. Then hit the advanced tab and click on the environment variables button at the bottom. You can either add the variable for just you or for all users on the system.
I don't know how to set environment variables for later versions of Windows but I expect Google might have some useful links.
From some of your comments, it is clear you haven't installed GNUStep in the same place as the instructions. Just do a file search for gcc.exe to find out where you have installed it.
I have built a .dll under WinXP that claims it can't find DWMAPI.DLL when it's loaded. The problem is that this DLL is a Vista DLL, and this a known issue for XP users that have IE7 installed. The recommendation is to uninstall IE7 or repair the .NET Framework via Add/Remove programs. I did the repair, and nothing changed. I'm not about to uninstall IE7 since there must be a better solution that's not the equivalent of "reinstall windows".
I've read bad things about people who attempted to uninstall IE7, so I'm reluctant to go that route.
I am using C++ under Visual Studio 2003 (7.1). I don't see an option where I may have forced delay loading at application launch. I just used default settings when I created the DLL project. I did just now find an interesting option, Linker->Input->Delay Loaded DLLs, so I put DWMAPI.DLL in there to force it to be delay-loaded. However, I get this when linking:
LINK : warning LNK4199: /DELAYLOAD:dwmapi.dll ignored; no imports found from dwmapi.dll
.. and it of course didn't change a thing when trying to load my DLL. For the heck of it, I added the whole tree of DLLs that lead to DWMAPI.DLL, and I get the same message. (For the record, it's foundation.dll->shell32.dll->shdocvw.dll->mshtml.dll->ieframe.dll->dwmapi.dll .)
To be more specific about what I'm doing, I am writing a Maya plugin and get the always-helpful text in the script editor:
// Error: Unable to dynamically load : D:/blahblahblah/mydll.mll
The specified module could not be found.
//
// Error: The operation completed successfully.
//
// Error: The operation completed successfully.
(mydll) //
I used Dependency Walker to initially track down the problem, and that's what lead me to DWMAPI.DLL. These are the message depends gives me, and DWMAPI.DLL is the only thing that has a yellow question mark next to it:
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
Gerald is right. Maya is, in fact, using a different PATH than the Dependency Walker. My plug-in loads another DLL (for image processing) that lives in the Maya plug-ins directory and depends found it with no problem, but Maya didn't. I had to add ";plug-ins" to the PATH in Maya.env.
Seeing as this problem wasn't related to DWMAPI.DLL after all, but DWMAPI is a common problem, I'll post the best link I found about the DWMAPI issue on Novell's website here. Basically, most programs will have this warning in depends.exe, but if there is a delay-load icon next to it, and you are sure that the program won't directly or indirectly call DWMAPI, then it's fine. The problem is elsewhere. If the delay-load icon isn't present, then you have to look at the /DELAY and /DELAYLOAD options in Visual Studio. The fact that depends gave me a "warning" and not an "error" was a clue to the fact that DWMAPI is not being loaded automatically.
Based on your updated problem, DWMAPI.dll is probably not your problem. Dependency walker will always give you that error whenever you are linking to mshtml as it always checks delay loaded DLLs.
At this point my best guess is that you have your project set to dynamically load the runtime libraries and the search path for DLLs is being changed by Maya. So it may be unable to find the MSVC runtime DLL(s). I haven't developed Maya plugins in a long time, but I've had that problem with other apps that have plugin DLLs recently.
Try changing your setting in C/C++->Code Generation->Runtime Library to Multi-Threaded rather than Multi-Threaded DLL.
Aside from that you can try fiddling with Dependency Walker to make it use the same search paths as Maya and see if you can come up with another dependency problem.
As a last resort you can launch Maya in a debugger and set a breakpoint on LoadLibrary and find out which library is not being loaded that way.
This is a tricky one. There's really 2 main ways you will get this error.
1) You have your project set to force delay loaded DLLs to load at application launch. DWMAPI.dll is a delay-loaded DLL and thus normally will not be loaded unless one of it's functions is called. That won't happen on XP unless you're trying to do it in your DLL. But it's possible to set a compiler option to force your app to load the delay loaded DLLs anyway. If you're doing that, don't.
2) It's often a false error that you will get from depends.exe when there is another problem. Run your DLL through dependency walker and see if there are any other dependency problems. If all else fails, try uninstalling IE7 and see if the problem persists. If it is a false error, after you install IE7 you will see the real error. You can install IE7 again afterwards.
I had exactly this problem.
Sneaky problem that took hours to solve.
Anyway. I compiled my managed C++ application on the release machine. Got complaints from customers that could not run it, worked like a charm on all of our machines.
It turned out that the release machine was automatically patched one night a month ago with the ATL vulnerability fix, and so was all other machines also, except one XP machine.
That particulare XP machine could not run the application either. Installed the ATL fix (see link below), and voilá, every thing worked just like before.
http://www.microsoft.com/downloads/details.aspx?familyid=766A6AF7-EC73-40FF-B072-9112BAB119C2&displaylang=en
So lesson learned, always check your intermediate manifests (found the in debug or release directory), that will tell you what version of the DLL that the program have been linked against.
Hope it helps anyone.
Try changing your setting in C/C++->Code Generation->Runtime Library to Multi-Threaded rather than Multi-Threaded DLL.