My Outlook add-in is compiled with platform target as "Any CPU" and it works fine in 32 and 64 bit Outlook now.
I want to use redemption.dll in my add-in to extent some functionality. I saw there are two versions of DLLs in the downloaded redemption package (redemption.dll and redemption64.dll) I want to use similar code below to use the dll in my add-in
Type t = Type.GetTypeFromProgID("MyDll.MyMailItem");
SafeMailItem sItem = (SafeMailItem) Activator.CreateInstance(t);
In this case which dll I refer to my project? redemption.dll OR redemption64.dll ?
How my project loads correct DLL in 32 bit Office and 64 bit Office?
The correct dll will be loaded by the COM system, not your code.
As long as both versions are correctly installed and registered in the registry, your code will work without any modifications. Note however that you will not be able to install the 64 bit version of the dll on a 32 bit machine.
You might want to look into using RedemptionLoader - you will skip COM registration completely, and RedemptionLoader will load the right dll for you based on the process bitness.
Related
We started to test OE12.4 to migrate our systems from 11.7, but 12.4 licenses doesn't include 32-bit versions of PROWIN32 and AppBuilder anymore. Therefore, we're unable to update and develop new applications using MSCOMCTL Treeview OCX, as we did until now. This isn't a problem for future programs, but for migration it is. We're unable to run programs from PROWIN (x64) which uses MSCOMCTL Treeview OCX's, as well as all other programs who uses 32-bit DLL's. The programs compile like a charm, flawless, but doesn't execute.
I tried to register MSCOMCTL OCX throug CMD in c:\windows\system32 directory but, as expected, it didn't worked. For this DLL, as a discontinued resource, Microsoft doesn't provide a 64-bit compiled code.
I'm aware that exist a open project called PureAblTreeView, which works pretty good and doesn't rely on DLL's dependency, but this object was built on ADM2 and the majority of my old programs are ADM1. Therefore, I'm unable to use that solution without rewrite my programs, which can't be done at this time. I even tried to "rebuid" PureAblTreeView as a SmartV8Object, but it didn't worked. Too many differences to be solved and too little time to achieve a running solution.
Is there any workaround for this situation, besides rebuild the programs?
Thank you all in advance.
If I am reading Knowledge Base article 000153835 correctly, then your issue should have been addressed in 12.4:
The 12.2.5 update and the 12.4 release have re-introduced the
AppBuilder to 32-bit OpenEdge. It is now available to run from the
installed Program Group icons.
I have created a x64 custom pipeline for Excel to XML decoding in BizTalk. I added the dll in the Pipeline Components folder in BizTalk 2013. But when I am trying to add this to the ToolBox it is not showing up. I need to the dll to be 64 bit since my OLEDB adapter is 64 bit and if I use 32 bit it will say provider is not registered on the local machine. Is there any workaround for this?
Make sure the DLL is GACed.
Restart Visual Studio after GACing the DLL (Visual Studio actually keeps this cached).
Right click on the Pipeline Designer toolbox, select Choose Items..., and browse to the DLL using the "Browse" functionality in the selector if it still doesn't show up.
If it still doesn't show up after manually selecting the DLL, it likely means that you are not properly inheriting/implementing the required interfaces and base classes. We could help you with this if you post the class definition (e.g. public class ExcelDecoder : IBaseComponent, etc.
Follow the steps in this article and let us know what happens: http://social.technet.microsoft.com/wiki/contents/articles/26404.biztalk-server-deploying-custom-pipeline-components-in-biztalk-server-2006-and-higher.aspx
Disclaimer, I have never built a custom pipeline component targeting x64 specifically.
However, you might be missing another gap. Where exactly are you seeing 'provider not registered'? Design time or runtime? Is the BizTalk Host Instance 32 or 64?
I have a project which is using Qt 4.7.4 version (also I can't rebuild it using qt4.8 or qt5 – there are a lot of errors appears, project is big and not mine so fixing issues would be even harder than erasing the whole code and write new code). So I need to make this project, well, working on NativeClient.
Is it even possible? I use Windows and Visual Studio, I was trying to google instructions about qt+nacl on Windows but just can’t find nothing.
Also which pepper version should I use if it depends on it?
Is your qt build supporting native client?
Please check out this
Windows
The Qt-Nacl is not support, for now, in Windows.
By the way, here is the github repository dedicated for it -> https://github.com/msorvig/qt5-qtbase-nacl
In the file nacl-readme it is written :
[...] Windows is not supported as a host platform.
Linux
If you want to compile in Linux, I have made a script that will compile Qt5.4 with NaCl with all the dependencies needed.
https://gist.github.com/theshadowx/438297ac465874a5e226
I also made a video that will show the different steps and a showCase at the end :
https://www.youtube.com/watch?v=q2pMv1Svtqw
I would like to release my app with both 32 and 64bit support. I am using elmah and SQLite. Both packages have a separate binary for 32 and 64bits. I cant add both 32 and 64bit DLL. I tried adding both 32 & 64 bit DLLs with a different filename in my bin/release folder and i get an bad image format error. (I tested by running on a Windows server 64 bit with both DLLs in the directory and on my system which does 32bit).
How do i release the app so the same folder can be run as either 32bits or 64bits?
Having just fought with 32- vs. 64-bit not long ago, I'll take a shot at this, at least with some general observations. I know this question is over a year old, but I hope the answer helps someone anyway, regardless of whether you "accept" the answer (which, in contrast to some, is not why I answer questions on StackOverflow).
First off, will 32-bit-only work in a WOW64 context in your situation? Often it will, and that can simplify your situation.
There are, however, situations in which third-party libraries make WOW64 not workable, at least according to their documentation, which is the situation I was facing. To solve the problem, I had to have both a 32-bit and a 64-bit build. If there is a way to release them both in the "same folders" somehow, I did not find it. However, it really was not too difficult to do so. I did have to edit the Visual Studio project files by hand. If I recall, the basic steps were:
Set up my build definitions in Visual Studio carefully, so that both release and debug versions had individual projects set correctly. That meant, in my case, that anything interacting with the native libraries at all had to be built in either x86 or x64 format, not Any CPU. Projects that are MSIL-only can be Any CPU, as far as I can tell.
Edit your project files (e.g., .csproj) so that the correct third-party DLLs are put in the correct folders based on the build. If there was an easier way to accomplish this, I didn't see it. There may be an obvious project file within your solution for this to happen, though it can really happen anywhere in your solution, so long as:
In your actual web project, make sure you add the project with the third-party DLL copy as a reference, even if the web project does not use this other project directly. That way, the files will get copied to your build directory. This seems like a bug in either MSBuild or Visual Studio to me, but as of VS2010, it does not seem to have been fixed. Also, if you need to copy the third-party DLLs to a directory such as App_Code, you may need to edit the web project file to accomplish that.
I would have to be at work to look at the project files and see what changes I specifically made, but these were the basic steps. Unless you can get away with your entire project being compiled as Any CPU, I think you will need to compile both a 32-bit and 64-bit version and deploy the one you need. Your actual code likely will not change, unless you are using native or unmanaged code.
Someone may come along who knows more about this than I, but I hope this helps someone. I'll try to answer any questions left in the comments.
I have a windows screensaver that I want to recompile using the QT libraries, so that I can make available for more platforms.
I am facing problems with the deployment on Vista and XP.
I compile my screensaver statically with MT, and run the dependency checker.
The results are:
MyScreensaver.SCR needs several DLLS, QTCORE4.DLL but no MSVCx80.DLLs.
So far this is fine.
My problem is that QTCORE4.DLL in its turn, does need MSVCP80.DLL and MSVCR80.DLL
As a result my application does not run on Vista systems.
Can I build QTCORE4.DLL to be statically linked the the microsoft libraries (maybe Libcmt.lib ?) so that I do not have any dependencies in the MS CRT DLLs?
Limitations:
I do not want to have the users install the MS VC redistributables. The screensaver is only 1 MB, and it is ridiculus to ask the user to do so many changes in his computer just for a screensaver.
I do not want to use the trick to put the MS CRT dlls in the same application path with the screensaver because screensavers are installed in system32, and I want to install the minimum possible files there.
Finally, I do prefer to produce a monolithic program, rather that a bunch of DLLs
I tried a full static compilation and link of QT, but this is not allowed (if I understood correctly, by the LGPL) and also it is not recommended according to this: http://www.qtsoftware.com/developer/faqs/why-does-a-statically-built-qt-use-the-dynamic-visual-studio-runtime-libraries-do-i-need-to-deploy-those-with-my-application
After trying for solutions in various directions, it seems the most feasible one is to use the QTCore4.dll and QTGui4.dll, but having them linked statically to MSVCRT. In this way, neither my program, nor the QT DLLs will have dependencies on MSVCRT dlls.
Is there a solution to this?
( I am new to QT programming )
Thank you,
Michael
I think they are concerted that parts of your application will be compiled with /MD(d) and parts with /MT(d), but if you control everything (including 3rd party libraries) then its pretty safe to use /MT(d).
You have two options:
Those dependencies are part of Microsoft Visual C++ Runtime Library, you can deploy that library in your installshield and user silently installs it, MSVCRT library not included in Windows by default, you must deploy runtime library in your installshield and copy Qt*.dll DLLs in your application directory.
Use Static Linking of Runtime and Qt main dependencies, with this option you have one executable file, but to static compile of Qt you must have Qt commercial License for commercial use.