I am trying to create a 64bit Gtk GUI with the GTK# library and am not having much luck. I'm using Visual Studio 2008, version 3.5 of C#. I obtained version 2.8.5 of the GTK# source and modified the makefiles to compile 64bit. I compiled this source against the 64bit version of GTK+ v2.22. The source compiled and I was able to import the "sharp" DLLs into my VS project.
When I try to run my app, it complains that it's trying to load a 32 bit GTK assembly. I altered the makefiles to use the 64bit versions of MinGW compiler and dllwrap and added the /platform:x64 directive to calls to CSC.exe. I am at a loss. I must be missing another flag/directive for 64bit somewhere.
Has anyone else tried to compile GTK# for 64bit? Does anyone know of a place to download precompiled 64bit versions?
I'm pulling my hair out trying to make this work. I would greatly appreciate any help on this.
Steve---
Related
I'd like to use Simd in Mono, but the following code is highlighted as error in MonDevop
using Mono.Simd
I already installed the "Mono 2.8 for Windows", what else I need to install to enable Mono.Simd?
In this link
http://tirania.org/blog/archive/2008/Nov-03.html
It talk about the tarbal, but after download it an uncompress it (mono-Mono.Simd.Math-942e804), there are many cs file and no dll file.
Did you add the Mono.Simd.dll to the build? MonoDevelop correctly highlights the error because in the assemblies you're using there isn't any Mono.Simd namespace.
Mono.Simd.dll is included in recent Mono releases.
As for the other answer, Mono.Simd works on any operating system on x86 and amd64, not only on Linux.
Mono.Simd only works when you run your programs on Mono runtime, on a supported operating system. If I'm not mistaken, it's currenly restricted to 32 & 64 bit Linux. Even if you manage to compile it on Windows, you won't get any speed benefit from it.
MonoDevelop for Windows runs on the .Net runtime, while the Mono.Simd.dll that comes with Mono 2.8 is installed in Mono's GAC.
You will need to Add Reference in your project to the Mono.Simd.dll that came with Mono 2.8.
It should be roughly in:
C:\Program Files (x86)\Mono-2.8\lib\mono\2.0\Mono.Simd.dll.
When I try to run the dll I compiled in Visual Studio 2010, I get the following message: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. I'm guessing this means that I am a too recent version of Visual Studio. Is there a way I can build the dll as an earlier version?
All assemblies in your final solution, be they dlls or exes, in different solutions or in the same one, must target the same version of the CLR. You can ensure they do by configuring targeting in your 2010 solution.
Most likely you're targeting 4.0 in your dll's project. Crank it back to 3.5 or earlier and see if that fixes the problem.
I currently have a VS6 unmanaged C library that I deliver as either a .lib or .dll. I want to upgrade to VS2010 but I still have users that are in VS6, VS2005, and VS2008.
Can a .lib or .dll built in VS2010 be used in VS6, VS2005, or VS2008?
Thanks!
It depends on the runtime used to build the libraries. I would typically run into this problem when upgrading solutions from VS2005 to VS2008. The default runtime libraries are different from edition to edition.
When you're building the .lib and .dll, those files are getting linked against those editions of the runtime. Problems will typically be found when you're debugging the program between different VS editions or running it on a non-developer machine when assemblies built with different runtimes attempt to pass information across boundaries. See http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx for details.
I know this is an old post but if anyone else comes across it this may be useful, upgrading from vc6 to vs2010 is a nightmare, but there is an alternative. You can upgrade to VS2010 environment while still using vc6 compiler. the tool you need is Daffodil and can be found here http://daffodil.codeplex.com/
This was our solution because the VS2010 environment is way more productive.
I've downloaded latest source from mono project, compiled it and everything works (c# projects, mod_mono, xsp) except vb.net. Vbnc, mono's vb.net compiler does not exist after compiling mono from source.
This is on CentOS 5, on Ubuntu 10.04 I installed mono packages via apt-get and vb.net just works.
What am I missing, or how to get vb.net support?
Mono's VB.Net support is in a separate module.
Either download the 'mono-basic' tarball:
http://ftp.novell.com/pub/mono/sources-stable/
or get it directly from SVN:
http://anonsvn.mono-project.com/viewvc/trunk/mono-basic/
or you can simply copy over what you need from a working system, like vbnc.exe and Microsoft.VisualBasic.dll.
All information about VB.NET on Mono is available at http://www.mono-project.com/Language_BASIC
Precompiled VB.NET assemblies can just be run with Mono.
The Mono VB.NET compiler is called vbnc.
If you need further help, can you please specify what exactly doesn't work? Does the compiler executable not exist, will VB.NET programs not run, or are you referring to MonoDevelop support?
(If the latter, make sure you have the latest MonoDevelop...)
I am trying to add a VC6 COM DLL to our VS2010RC C# solution. The DLL was compiled with the VC6 tools to create an x86 version and was compiled with the VC7 Cross-platform tools to generate a VC7 DLL.
The x86 version of the assembly works fine as long as the consuming C# project's platform is set to x86. It doesn't matter whether the x64 or the x86 version of the DLL is actually registered. It works with both. If the platform is set to 'Any CPU' I receive a BadImageFormatException on the load of the Interop.<name>.dll.
As for the x64 version, I cannot even get the project to build. I receive the tlbimp error:
TlbImp : error TI0000: A single valid machine type compatible with the
input type library must be specified.
Has anyone seen this issue?
EDIT:
I've done a lot more digging into this issue and think this may be a Visual Studio bug. I have a clean solution. I bring in my COM assembly with language agnostic 'Any CPU' selected. The process architecture of the resulting Interop DLL is x86 rather than MSIL.
May have to make the Interop by hand for now to get this to work.
If anyone has another suggestion let me know.
This issue can be resolved by opening the CSProj file and adding the following node to any of the '(Configuration)|Any CPU' nodes that are missing it:
<PlatformTarget>AnyCPU</PlatformTarget>
If this node is not present TlbImp will default to x86 and cause issues.