I'm in need of downgrading from comctl32.ocx v1.4 to v1.3.
I have copied the dll, ocx and oca from a pc with the v1.3.
Unregistered the ocx and registered again but it didn't work v1.4 persists.
If by "1.4 persists" you mean that your project is still trying to use 1.4, this is because it is referenced as 1.4 in the *.vbp file.
if that is the case:
open your project (*.vbp file) with notepad and change the 1.4 to 1.3.
This will make the project use the correct dll version you want it to use. i've had a similar problem with projects that i was working on with a colleague, since our versions of a particular dll are different. Changing this value before opening allows us both to work on it (bit of a hassle but reasons for it). hope it helps.
Related
Basicly I'm super newbie and started internship in IT company. I installed VS with Xamarin. The problem that I'm facing is very frustrating. So even when i create empty project I can't compile it and get error like this :
Severity Code Description Project File Line Suppression State
Warning major version 52 is newer than 51, the highest major version supported by this compiler.
I searched all over google and asked so many people and still no fix of my problem. If anybody can help me via skype or teamwiever i will APPRECIATE so much. My skype: toniterdal , feel free to add me.
I was having the same issue, and tearing my hair out. I had the JDK Version 8 installed, but these warnings wouldn't go away, and eventually they generated a build-breaking error.
When I went to Tools -> Options -> Xamarin, and looked at the Android Settings, the Java Development Kit Location was pointing to jdk.1.7.xxxx, in Program Files (x86).
I changed it to 1.8.0_101, in Program Files. Then I restarted Visual Studio, and the same error happened again. Somehow, Visual Studio was detecting Version 7 of the JDK and pointing it to that automatically.
So the solution turned out to be very simple. As well as installing Version 8 of the JDK, UNINSTALL Version 7 of the JDK. As soon as I did that, Xamarin turned out to be much better behaved. This step solved a whole bunch of seemingly unrelated problems.
That error is telling you that the Java Class version that is being loaded was compiled with Java 8 (52) but Java 7 (51) is trying to load that compiled class.
Java 7 uses major version 51
Java 8 uses major version 52
Check which Java version(s) are installed on your machine and review Xamarin's requirements and Java installation steps (linked below)
Installing the Java SDK (JDK)
For people having problems with setting the appropriate JDK version, you might want to try to override this setting in the vs2015 options dialog:
Delete bin folder and obj folder and run the project it will be work fine
You have a bad proguard.jar file, you need to replace this .jar by a correct version. The steps below describing how to do that. Some colleagues had the same problem here.
Go to Preferences => SDK locations and copy the Android SDK location.
Go to that folder (mostly /Users/USERNAME/Library/Developer/Xamarin/android-sdk-macosx) and go to the folder tools/proguard/lib.
Here you find a proguard.jar.
Rename this to proguard_OLD.jar.
Download the last proguard file (like this one https://sourceforge.net/projects/proguard/files/)
Unzip and place the proguard.jar in the tools/proguard/lib folder
Rebuild your Project
Everything should be fixed!
You can find more info about the bug here:
https://releases.xamarin.com/technical-bulletin-android-sdk-build-tools-24/
For me worked to change the SDK as well, but under Options->Xamarin->Android Settings, I don't have Cross Platform in Options for VS 2015Pro
Note for Windows 64 bit users, the JDK has to be the x86 version not the x64 version.
E.g. C:\Program Files (x86)\Java\jdk1.8.0_111
Kaloyan you can find the setting for the Java SKD under Tools->Options and the click on Xamarin in the Options list, then select Android Settings. I installed the latest Java version (8.0.111) and then did a clean on my project and it runs fine now with no errors. Thank you everyone for your posts!
In my case, i had to reinstall the JDK 8 (the last version) because other versions JDK 7 couldnt work even with new projects or clean up projects, and also i had to do a clean install of the android sdk.
This is how I solved the same issue I faced today:
From Control Panel > Uninstall a Program > uninstall the older Java versions which are on your system.
You should only have Jdk 1.8 and Jre 1.8 on your system.
Now go to C:/Program Files/Java and delete all older java versions.
If you have setup your JDK 1.8 and JRE 8 in C:/Program Files (x86)/Java then cut paste them into C:/Program Files/Java folder.
Then I restarted IntelliJ IDE which I am using. It automatically asked to update the path of SDK. Update the path to point to Jdk 1.8 and then I recompiled my files and things started working well.
Hope it works for you too!
In my case, I had just deleted .class files and worked fine.
I have two versions of abcpdf running on the same machine. One of the projects is using the older version 7.1 and the other one is using the newer version i.e 8.1.
When i try to build, the visual studio automatically picks up the latest version on abcpdf 8.1 and throws the following compile error
'WebSupergoo.ABCpdf7.Doc.Doc()' is obsolete: 'Don't use ABCpdf7 namespace - use ABCpdf8 instead.'
Please suggest me where i am going wrong.
Thanks.
Uninstall both versions from the GAC, and re-start IIS to get them cleared out.
Then reference the specific dlls from your projects manually, following the instructions for a manual install:
http://www.websupergoo.com/helppdf5net/source/3-concepts/6-installation.htm
You will need to point your project references to the two different AbcPdf.dll files (one for each version), and you will need to make sure that either ABCpdfCE7.dll or ABCpdf8-32(or -64).dll is copied to the bin of the correct project.
Can I use new SDK directories that comes with VS2010 for VS2005 ?
I expect you can, but unless you need that specific version the simplest thing to do would be to download the latest Windows SDK instead:
Microsoft Windows SDK for Windows 7 and .NET Framework 4
This is more recent and can (IIRC) automatically integrate into VS2005.
If there is going to be an issue with this or with the VS2010 SDK then it will be because the .lib files are incompatible, e.g. through an object file format change or through a whole-program-optimisation intermediate representation change. However most if not all of the .libs in the SDK will just be DLL headers and so this shouldn't be an issue. (In the SDK release notes there is actually a link to a supported hotfix that improves compatibility between VS2005 and VS2008 objects but it sounds like VS2005 SP1 will usually be enough.)
There's a slim chance that the header files might not work (or might assume a different set of default defines) but in general the Windows header files are very careful with defines and version testing that I doubt this would be an issue.
If you're asking if you can use ATL + MFC from the later version then I think this is less clear cut, and may require a recompile of their sources in the older compiler. In that case I think your best option might be to upgrade to VS2010 if that's possible.
According to this article, the version of a referenced dll is embedded in the exe file.
Using ProcExp, I can see that the runtime loaded dll is indeed the latest dll available on my machine, but I'm interested to know the linked version.
As a side note, I built the project using the VS9 msbuild, and interested in the VC runtime (msvcr90.dll) version. In the VC9 redist folder it is 9.0.30729.1, runtime the .4926 is loaded.
My questions are:
Is there any tool with which I can extract the dll version linked to (from the dll/exe)?
Which version does VS link to by default? The one found in its redist folder?
Thank you.
Dependency Walker might do it.
Actually, Dependency Walker seems to not read (or at least display) the version linked in the file.
But I found that I can use mt.exe from the Windows SDK or ResEdit to read the embedded manifests.
Also, to summarize my findings (targeting amd64 using msbuild with the Windows SDK for Win7, which seems to use VS9 (SP1?) libs):
Without special effort, VS9 (non-SP1) version 9.0.21022.8 of the CRT is written in the embedded manifest. Maybe this is a VS9 platform baseline.
Runtime the newest dll gets loaded, according to the SxS policy (good read can be found here, along with the article referenced in the question).
People seem to had problems when the appropriate policies are not installed (via the redist package for example), see here and [here] and 4[here]5.
The latter SO tells that if _BIND_TO_CURRENT_VCLIBS_VERSION=1 is defined, then the linker would link against the VS9 SP1 CRT (version 9.0.30729.1), which as noticed before, is indeed in the redist folder.
For future account, it would be nice if:
There would be a table with CRT version X.Y. introduced in OS/SP/etc Z.W.
If one could know that what is a safe version to target, which is possibly available on most users machines by default.
Is it important for a VB6 app to refer to certain OCX versions?
I have noticed that if I put my VB6 app code through the IDE on one machine then the form files will refer to different version of some OCXs than if I use another machine.
What is the rule of thumb with this? Is it safe to assume that most of these old OCX versions will be compatible with each other and so I shouldn't worry?
Some of the OCXs in question are:
RICHTX32.OCX v1.1 and v1.2
COMCTL32.OCX v1.2 and v1.3
You should probably install the ocx files your application was created with replacing existing versions only if the version you are installing is newer. Here is a question How can you force VB6 to use the DLLs and OCXs from the app directory? that explains installing all your application files into the same folder and running from there.
Is it important for a VB6 app to refer to certain OCX versions?
Yes, because you are "binding" your code to the interface of the ActiveX control.
What is the rule of thumb with this?
Make sure "Upgrade ActiveX Controls" is checked. Under Project properties, on the General tab.
MSDN Search of "Upgrade ActiveX Controls" at http://social.msdn.microsoft.com/Search/en-US?query=%22Upgrade+ActiveX+Controls%22&ac=8
Is it safe to assume that most of these old OCX versions will be compatible with each other and so I shouldn't worry?
Do not worry. The two controls in question are Microsoft controls. One for the rich-text-box and the other is a wrapper to the Windows common controls. You should have no problems with these controls. (There were issues with the rich-text-control on older versions of Windows, but this has been resolved on Windows NT versions.)
For other ActiveX controls, usually from third-party vendors or in-house, you may have a problem. In your specific case, I would not worry about it, until it happens. This is a very complex subject.
How To Use Project and Binary Compatibility at http://support.microsoft.com/kb/161137
MSDN Search of *Binary compatibility at http://social.msdn.microsoft.com/Search/en-US?query=%22Binary%20compatibility%22&ac=8
It may matter if the changes in versions create "breaking" changes. If on your developer machines it doesn't seem to affect the application in an adverse way you are likely fine on those machines. However, if/when you need to deploy this code to one or more users machines you will also need to make sure these controls are on those machines along with a version that is compatible with your code.
You can create an install package that would wrap up and install the versions you are using to ensure this would not be an issue.