Error with Virto Commerce Smart Caching Module after fresh install from source code - virtocommerce

After doing a fresh install of the VC platform and VC storefront from source code, I chose to install the sample data. I am getting an error in the Smart Caching Module, which states Module platform version 2.13.28 is incompatible with current 2.13.26;
In my VC Platform solution, I can see the version is in fact set to 2.13.26 in my common assembly file - and in my Smart Caching Module the target version is in fact set to 2.13.28.
How can I roll back the Smart Caching Module to target the 2.13.26 version? Or is it easier to upgrade the platform to version 2.13.28?
Thanks

Yes, the easiest way to update your VC platform to the latest version. https://github.com/VirtoCommerce/vc-platform/releases

Related

DNN module error after trying to move it from dnn7 to dnn9

I previously have this FAQ module installed on an old system running on DNN 7 and I tried using the same module on a site running on DNN 9.4.1 and I get the following errors:
and
I obtained the resourse file of this module from the package creator on the old system (DNN7) and installed it onto the new system (DNN9).
Does this happen because of the way i got the resource package or does it have to do with compatibility issues like this module is not supported by later versions of DNN?
Thank you.
In DNN 9.2 & later the Telerik Grid Components were moved to a Deprecated assembly from the standard DotnetNuke.WebControls so all references to these wrappers, such as dnngrid will need to be updated.

Compiling Titanium Modules from GitHub

After a few days of failure I realize I need more insight than google can deliver.
I am attempting to include a module in my otherwise working fine Titanium project but am not having any luck. The module in question is Ti.MapPlus, a fork of the standard Ti.Map module that I am already using. The GitHub repository does not have a compiled release, and it is not available via Gitt.io.
I have tried to create a new Mobile Module Project without success; but suspect that this is the best route.
Can anybody walk me through the steps of getting the module working globally?
There are some releases here: https://github.com/AppWerft/Ti.MapPlus/releases

Ant Script (qnx.xml) fails while packaging BB10 build

I have created an application for BB10 using IBM Worklight. The application version currently on production in v1.0. The application descriptor has version 1.0 for BB10.
I want to promote a new build with version 1.1. But, before releasing the build, I want to create interim builds for testing. Ex: 1.001, 1.002 and so on.
I am using antcontrib qnx.xml to package and sign blackberry 10 builds. When using this build process, the blackberry10 build fails stating: Native Packager exception occurred.
Also, from Worklight perspective, the versions that we can provide is only in format x.y. We cannot have x.y.z as the version in the application descriptor.
In such a situation, how do I fix this issue of releasing interim builds with version 1.001, 1.002 and then release the final build 1.1?
You mention an exception, but do not provide any other details such as reproduction steps. Not helpful.
What makes you think that in application-descriptor.xml you can only use x.y as the version number? I used 1.0.1 and 1.0001 w/out any issues. You'll need to better explain your issue.
<blackberry10 version="1.0.1"/>

Worklight 5.0.6 wipes out native customizations in shell

I upgraded my environment to v5.0.6. Problem is that everytime i start Eclipse it does this:
[2013-04-19 18:38:41] FWLST1017I: [AppShell] upgraded to the latest
platform version.
When this upgrade takes place, it reverts my templates and adds class files to the iphone\native folder and removes the plugins I configured in the shell:
Removes all my custom plugins from components/AppShell/iphone/native/Classes
Resets project.pbxproj.wltemplate.wluser to stock removing includes for my classes
Resets config.xml.wluser removing all mappings to my plugins
It also always shows at the end of the upgrade process:
Failed to upgrade Worklight project 'AppMobile' to the latest platform
version. [null]
Is that why it keeps running the upgrade and reverting my changes?
According to your question, you have some .wluser files, which means that something is wrong with your project.
Can you please let me know whether the problem still exists and whether you still have those files in you project?

Library search path for libstdc++

I have compiled shared libraries dynamically linked against libstdc++.so using GLIBCXX_3.4.11. I want to send my code to someone whose stdc++ library is only of version 3.4.10. Rather than ask him to update his library version (this is a software customer, so I can't assume they'll be willing or able to change system files) I would like to ship the appropriate version of libstdc++.so, placed in a lib folder with the directory location of my code. How do I get my own code to use the appropriate (later) version? I find that /etc/ld.so.conf includes the directory /lib64, where an offending older version of libstdc++.so resides. Setting LD_LIBRARY_PATH does not override this. This seems to deviate from the advertised behavior. Any idea why this is happening? How do I complete my rather simple task?
Thanks.
I understand that this question is old, but I found it while trying to sort out my own linking trouble which was similar. You will have to build your program against a version of libstdc++ which is compatible with your colleague's version of the library. The easiest solution, of course, is to link against his version of the library so he doesn't need to make special tweaks on his side to link your library.
To do this, you will want to install a version of GCC which can build binary compatible libraries so you can actually link against his version of libstdc++. GLIBCXX_3.4.11 is from gcc-4.4 and later, so you will need gcc-4.3. Build your program using this and you should be in good shape.
You can consult the following page for a list of library ABI compatabilities:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
You could also build an rpm/deb which requires the version of libstdc++ you already have and if it's not available, refuse to install. This gives you a bit of an interface which gives him a promise that if his system is setup with the correct dependencies, he can use your library. In that sense, it's like a loose SLA for your library in what you do and don't support.
Hope that helps!