Here's my issue: I wrote a VBA class module that consists of commonly used methods and functions. I am continually refining the module and making changes to it.
The problem is that I include this module in almost all of my VBA projects and I really don't want to keep importing the new module into each project everytime a change is made.
My question(s): Would it make sense to create a DLL that all of my projects would link to? Or is there an alternative solution that would make more sense?
Thanks
If you're going to create a DLL, which I think makes perfect sense, you might want to do so in a language built on the .NET framework, such as VB.NET or C#. This provides the ability to combat the 32bit and 64bit issue by building both 32bit and 64bit versions.
It's worth noting that a 32bit DLL running on Windows 64bit with Office 32bit will function just fine. It's when the user is running Office 64bit that you need to worry.
With regards to deployment, you could spend a little extra time to create an installer (using NSIS for example) to make deployment much simpler. This installer would serve the purpose of registering the DLL on the target machine. You could also make the installer install both 32bit and 64bit versions of the DLL to guarantee the DLL will be compatible, regardless of the users configuration. I like the idea of registering both bit versions to avoid the scenario where a user has a Windows 64bit/Office 32bit environment and decides to upgrade their Office version to 64bit. If you have the 64bit version already installed, the reference to the DLL will resolve correctly.
Related
I'm using Linux (Ubuntu) 64bit system and need to make a DLL for MetaTrader4.
I did read lots of things I found about it, but it is very chaotic and confusing. There are many DLLs which are not acceptable for MT4. So far it seems that I need: a 32bit DLL made by using C++. There might be other criteria that I don't know. What IDE/compiler (free, if possible) should I use for it on my 64bit Linux system?
I've never made any DLL, so please tell me if there are other important conditions as well that I should know.
The only way to create a dll for Linux is using .net core however this will not work for anything MT4 related.
MT4 in all its variations is hooked into specifics system level api on windows and the only way to run anything dealing with it on Linux is to build it for windows and run whatever you write from inside wine.
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
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.
I'm trying to investigate why would my app, written in VC 2008, crash on bare Windows XP with c0000005. It works great on any windows vista and 7. On XP it would crash with no additional info. Below are the details and the result of a few days worth of my headaches, eliminating one reason after another. Here's the details:
I have Win7 ultimate with XP Mode with iexplore 6 and presumably no patches whatsoever.
I install my program and nothing else, since it is supposed to be install-and-run thing with no additional packages needed.
My app has compiled-in VC2008 runtime (using /MT, as opposed to /MD compiler switch)
I'm using firebird embedded, which needs VC2005 (edited, i wrote VC2008 before) libs for itself anyway, so i put them in my app's working dir
when i install VC++ 2008 on this XP Mode machine, it doesn't crash anymore, so debugging this way is impossible
I've narrowed this error's occurence down to the VC2005 runtime - right after i install it my app stops crashing. But i don't know what could be using it's components. When running the release version under VC2008 IDE, nothing shows any vc2005 libs being loaded (weird, if i say so myself).
My app's linker's dependencies lists these (i added only the first two, the rest was there courtesy of VisualStudio): jpeg.lib, gdiplus.lib, kernel32.lib, user32.lib, gdi32.lib, winspool.lib, comdlg32.lib, advapi32.lib, shell32.lib, ole32.lib, oleaut32.lib, uuid.lib, odbc32.lib, odbccp32.lib, comctl32.lib, %(AdditionalDependencies)
I am also using IBPP firebird interface, which loads these dynamically, so they are present in my app's dir (they need msvc?80.dlls):
fbembed.dll, ib_util.dll, icudt30.dll, icuin30.dll, icuuc30.dll, msvcp80.dll, msvcr80.dll
Please advise why would vc2005 runtime be a remedy for my app to not crash on a bare Win XP. Or how could i debug that one without installing vc 2008 on target machine. I'm starting to blame windows xp's components. Ultimately i want my app to not require any additional packages, such as VC2008 or 2005, especially when no component of my app requires the latter.
I am also using IBPP firebird interface ... msvcp80.dll, msvcr80.dll
The answer is in your question, these DLLs are VS2005 runtime support DLLs. They cannot be stored in your exe directory, they must be registered in the side-by-side cache. This does not typically cause an AV, but it isn't impossible if the code doesn't check the return value of LoadLibrary(). You can download an installer for them from Microsoft. It doesn't otherwise have anything to do with Windows XP, you just happened to try to run this program on machines that already had the DLLs installed. Very common on a dev machine for example.
If you don't want a dependency on them then you'll have to rebuild those DLLs that require it. Which is a good idea, having a dependency on more than one version of the CRT is pretty unhealthy.
If you are wondering why you are having to deal with this: it was Microsoft's attempt to put DLL Hell in the developer's lap instead of the user's. They've since withdrawn this, VS2010 again makes it a user problem. That was a pretty big party in Bangalore, I'd imagine.
My application which is built on VC++ 2008 , when run on a freshly installed XP shows an error that asks dotnet.fx to be installed. And also i faced similar problem when i tried to run it on another xp system after i installed that, it started to run.
Is there any way that i can make my application independent of all these additional installs ?
Are you sure you didn't compile managed C++ (targetting CLR) instead of real C++. In the former case dotnetfx is the .NET runtime you absolutely need and not some optional addon. In the latter case you need only the VC_redist in either x86 or 64bit variant. That installs the C and C++ dlls only. These are side-by-side assemblies and must match the version you compiled for.