Version 3.11 & 3.15 NuGet Packages requires IKVM.8.1.5717.0 yet is appears both are compiled against Version=7.2.4630.5 when looked at with ILSpy.
Running C# Examples show it will only work against IKVM.OpenJDK.Core, Version=7.2.4630.5.
I have a requirement of IKVM.8.1.5717.0 as I have other packages running in a WebSite which becomes problematic. We don't really want to change architecture to accommodate both 7.2 & 8.1.
Re-compiling the Org.Carrot2.Core.dll with IKVM.8.1.5717.0 from source and reproducing the Org.Carrot2.Core.NET.dll throws a
Binary format of the specified custom attribute was invalid.
in the org.carrot2.controller.process(Map attributes, params Class[] processingComponentClasses)
Is there a downloadable stable version of 3.11 or 3.15 with IKVM.8.1.5717.0 somewhere?
Unfortunately the answer is no: we don't have a binary build against IKVM 8 because it didn't pass our internal tests. IKVM's development has been ceased and we don't plan to upgrade to IKVM 8 at this moment (note that there are no stable versions of IKVM 8 [1]).
[1] https://sourceforge.net/projects/ikvm/files/ikvm/
Related
Today I start getting this message when I open Delphi XE6.
The procedure entry point #Idstackwindows#TidStackWindows#NetworkToHost$qqrj could not be located in the dynamic link library C:\Program Files (x86)\Embarcadero\Studio\14.0\bin\MetropolisULiveTile200.bpl.
I answered Yes to "Do you want to load it next time".
When I look in the folder I see that the MetropolisULiveTile200.bpl is in the folder.
I haven't installed anything new since 9/24/2020, when I installed the latest version of Indy. I have used Delphi XE6 every day since I upgraded.
It looks like any program I have are building and compiling without any errors.
I search the internet, but was not able to find any with the same problem.
This issue is documented in Indy's installation notes:
In D/CB/RAD XE3+, Embarcadero's Metropolis UI LiveTile framework is compiled against the Indy 10 packages that ship with the IDE. Installing a new version of Indy will render LiveTiles unusable, as it will not be able to load the Indy packages anymore, and LiveTiles cannot be recompiled by end users. If you need to use LiveTiles then you will need to maintain the original Indy 10 packages for use in LiveTile projects. You can use a separate installation of Indy 10 for non-LiveTile projects. This has not been addressed by Embarcadero yet so Indy 10 upgrades and LiveTiles can co-exist.
If you were not getting this error between 9/24 and today, and now you are, then you probably opened a project today that has a dependency on (or at least enables) the LiveTile package, whereas projects you worked on earlier do not.
Will a module created for OXID 6.0 be backward compatible with lower versions (i.e.: OXID 5.0) in terms of installation and activation?
If the new metadata version 2.0 and namespaces are used the module will not be backwards compatible. Modules for version 4/5 did not use namespaces and installation was done by file copy, the new recommended way is to use namespaces and install the module with composer.
Also the database layer has changed in Version 6, if the module has interactions with the database the corresponding code slightly differs from version 4/5 (using AdoDB) to version 6 (using doctrine).
So it might be possible that a module created for OXID 4/5 will work in version 6, but in most cases you will need separate versions of the module.
More information can be found here: https://docs.oxid-esales.com/developer/en/6.0/
No, this will never work this way. OXID6 provides only temporary backward compatibility for older modules. I think they will stop supporting older modules when all oxid-esales modules will be rewritten to new oxid6 format.
I want to install a software on my PC but when i clicked to install it I got
CVIRTE.dll Missing error
I search for this error but unable to download this dll file. Please provide any link to download this file
Any help would be highly appreciated
I guess this is the CVI Runtime Engine. It is needed to run Applications that were made with LabWindows/CVI or MeasurementStudio by National Instruments ( http://www.ni.com/lwcvi/ ). Usually, programmers of such applications also generate a Windows Installer Package for the application, which also does the installation of the CVI Runtime Engine. So , once you installed a CVI application like that, you usually can run other CVI application just by copying them (as long as they do not need additional packages from Ni). So, either run an installer of another application made with CVI, or just install the RTE.
Be aware that there are new versions of the RTE with every new version of CVI, and the library is getting larger and larger. So maybe you can go for an older version of the RTE, it could be more compact.
The 2015 version of the RTE can be downloaded here :
http://www.ni.com/download/labwindowscvi-run-time-engine-2015/5374/en/
Good luck !
I read the manual available here https://cwiki.apache.org/confluence/display/FLEX/Apache+Flex+SDK+Mavenizer. But it's confusing me. It's told that I should apply converter seprately to Flex SDK and Air SDK. But at present both of SDKs downloaded and merged by current Apache Flex Installer (should I download packages manually?). Also I don't have the flex-sdk-converter-1.0.jar. After build the mavenizer I have air-converter-1.0.0-SNAPSHOT.jar, flex-converter-1.0.0-SNAPSHOT.jar, base-converter-1.0.0-SNAPSHOT.jar and flash-converter-1.0.0-SNAPSHOT.jar.
How to use those tools to properly put Flex and Air SDK to the maven repositoy?
I also faced the same problem 2 months back.
The documentation on the website was for older version.
It has been updated on November 03rd.
Can you try again by following that?
This appears to be the current documented process now.
https://cwiki.apache.org/confluence/display/FLEX/Preparing+FDKs+for+Maven+builds
In a C# prject, What is the difference between MvcMiniProfiler.dll (version 1.7) and MiniProfiler.dll (2.1) ?
They are both the same thing, MiniProfiler.dll (2.1) is the latest version. The project got renamed from MvcMiniProfiler to just MiniProfiler around the 2.0 time; because it is also usable on Ruby now (i.e. it's not just an 'mvc' profiler anymore).
See here, specifically the section "No longer MVCMiniProfiler"