Can't load RemObjects.InternetPack under Mono - linux

I wrote a program on Windows 7 with Delphi Prism. I took the executable and try to run it on Linux under mono. At which point, mono raised the following error. Is this mean RemObjects components are only meant for windows environment? If not, how do you resolve this exception?
Could not load file or assembly 'RemObjects.InternetPack, Version=2.0.47.845, Culture=neutral, PublicKeyToken=3df3cad1b7aa5098' or one of its dependencies.
Unhandled Exception: System.TypeLoadException: A type load exception has occurred.
Thanks in advance,

You need to deploy and register RemObjects InternetPack on the Linux machine. It's not part of the default runtime.
Think of it like building a Delphi Win32 app with runtime packages. When you deploy the application to other machines, you also have to deploy the runtime packages.
Deploying .NET packages is a totally different question (and not really Delphi or Prism related). You might want to search here on SO first, and if you don't find an existing answer then post a new question.

Related

custom attr errors when trying to use NLog on Mono on openSUSE

I'm researching how much of the solution I have for Windows can be simply transplanted to Linux. Most of my actual program can operate, but our favourite logging module on Windows is NLog.
I'm having a problem on openSuse. When NLog starts (i.e. valid configuration is found), the program fails with several errors of the form:
Can't find custom attr constructor image: /share/MonoSIMON/MonoTestConsumer/NLog.dll mtoken: 0x0a000358
The error appears 9 times with NLog 3.2.0.0.
Initially I was running with a newer NLog V4.3.1.0, and the result is the same although there are around 15 copies of the error instead.
I'm not compiling Mono or anything, it's all as standard packages. I'm targeting Framework 4.5, it's a Console App, and I'm really not doing anything special.
Is it possible to run with NLog on openSuse.
Thanks for any help.
Mark
I eventually worked this out. Julian pointed me back in the direction of the NLog issues board, but that package name doesn't work on openSuse 42.1.
A search on www.rpmfind.net shows that the system.service model assembly is actually in the openSuse 'mono-wcf' package.
zypper install mono-wcf
Fixes the NLog problem.
Cheers.

VC++ Runtime to terminate it in an unusual way

My Unmanaged VC++ MFC (No .NET used, No CLR support, Use MFC in shared DLL) application trying to deploy with visual C++ runtime files as private assemblies.
It is properly running on windows 7 fresh installed computer.
But I gives “This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.” error in fresh installed wondows XP sp3 computer.
I checked in application event logs. But there also no more details, just showing the same error.
Then I read these threads and surf around the internet.
Thread - 1
Thread - 2
Article -1
But couldn't find any solution clue or trouble shooting method. so here looking for some assist.
The easiest way to test is to install depends on the computer. Most likely, your application is built to use a later version of C++ runtime libraries, e.g. <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.4053' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />, but on the XP system it is an older version.
You would need to check what version of the runtime library used by analysing the program's manifest. Then check what depends is showing.
If the required version of runtime is missing, distribute it with the program's install.
On the side note, you could consider switching to the static link. The size of the binaries will be bigger, but these type of problems will be gone

Windows Forms Control Library x86 no working?

Not sure if anyone else is having this issue.
I am attempting to create a windows forms library control. I need the control to run in an x86 environment. So, the first thing I do is go into the properties of the project and switch the platform target to x86.
I try running the application and I get the lovely error message referencing the assembly I am trying to create and stating: An attempt was made to load a program with an incorrect format.
I have not added any references nor any code, just trying to create a control in x86.
I am using a windows 7 64bit machine with VS2012 trying to write the app in .NET 4.5. I have to do the project in x86 because I am using some OCX that are x86 only.
Has anyone run into this?
go into the properties of the project and switch the platform target to x86
Well, that worked. Instead of a confusing COM exception (typically "Class not registered" which has several possible reasons) you get an early .NET exception that tells you that you are using the library wrong.
To test your library project, you needed to create an EXE project that had a reference to the library project. What you forgot to do is change the Platform target setting on that EXE project. Which matters because only the EXE project can determine what the bitness for the process will be. It is the one that loads first, a library project has no say. It can only veto the choice, the BadImageFormatException is that veto.
So you have to change the Platform target setting for the EXE project to x86 as well.

Why can't my program find the VC++ Runtime?

I'm trying to package Unison (not really my program) into an easy to use installer. Tl;dr: a screenshot.
When I install and run it on the test machine, it says This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem.
The event log reveals that it can't find Dependent Assembly Microsoft.VC90.CRT.
Search reveals that the "missing" dll is in fact in C:\Windows\WinSxS
So what's wrong?

What makes deployment successful for some users and unsuccessful for others?

I am trying to deploy a Visual C++ application (developed with Microsoft Visual Studio 2008) using a Setup and Deployment Project. After installation, users on some target computers get the following error message after launching the application executable: “This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem.” Another user after installation could run the application properly. I cannot find the root cause of this problem, despite spending several hours on the Visual Studio help files and online forums (most postings date back to 2006). Does anyone at Stack Overflow have a suggestion? Thanks in advance. Additional details appear below.
The application uses FLTK 1.1.9 for a GUI library, as well as some Boost 1.39 libraries (regex, lexical_cast, date_time, math).
I made sure I am trying to deploy the release version (not the debug version) of the application. The Runtime library in the Code Generation settings is Multi-threaded DLL (/MD).
The dependency walker of myapp.exe lists the following DLLs: wsock32.dll, comctl32.dll, kernel32.dll, user32.dll, gdi32.dll, shell32.dll, ole32.dll, mvcp90.dll, msvcr90.dll.
In the Setup and Deployment Project, I add the following DLLs to the File System on Target Machine: fltkdlld.dll, and a folder named Microsoft.VC90.CRT with msvcm90.dll, msvcp90.dll, mcvcr90.dll and Microsoft.VC90.CRT.manifest.
The installation process on the target computers getting the error message requires having the .Net Framework 3.5 installed first.
Any suggestion? Thanks in advance!
Add the Visual C++ Redistributable to your Deployment project and be sure to run Setup.exe instead of the MSI when installing. This will invoke the VCRedist bootstrapper to ensure your PC has those pieces before installing your app.
Dependency Walker only shows static (link time) dependencies - it cannot possibly know about dynamic dependencies such as COM objects.
I had a similar problem after the ATL security updates last year. My app needed a later version of the C++ runtime libraries than the deployment project included.
Try running Windows Update on the target machines after installation, or download and install the latest (28 July 2009) C++ redistributable package directly.
http://support.microsoft.com/?kbid=973551
That solved the problem for me. I haven't fixed the deployment project yet though.

Resources