My software is currently using a version of Redemption from 2015, some customers are running into freezing issues on the current version of Outlook, so I'm interested in upgrading to the latest version of Redemption. Will the latest version of Redemption be backwards compatible with the functions we are already using from the 2015 version of Redemption?
Yes, all versions of Redemption are backward compatible (binary and source code) – you can just swap the dll.
Related
I'm using the Excel Interop API for manipulating excel sheets, because this seems to be the best api for using formulas.
My question is that how wide is the support for this API?
For example if someone who has an older or newer version of Microsoft Office than me, will they be able to use the software?
I'm using it with Office 365.
My question is that how wide is the support for this API?
For example if someone who has an older or newer version of Microsoft Office than me, will they be able to use the software?
The answer is yes, your software can be run with different Office versions. You just need to make sure methods and properties exist in the installed version by checking the host version and making a decision to call a particular method or property introduced in recent versions.
So, I'd suggest using the lowest version of interops libraries which corresponds to lowest Office version supported by your software. By using lowest interop version you can be sure that you deal with properties and methods available in all Office versions and no exceptions will be thrown at runtime.
If you need to use methods and properties available in latest Office versions you may consider using the late-binding technology available in .Net applications with System.Type.InvokeMember method. Read more about that in the Supporting several Office versions in an add-in. Interop assemblies and late binding. article.
I am working on a PCL project that is using Profile44 as TargetFrameworkProfile. When I try to install NodaTime 2.2.4 I get the following error message:
Could not install package 'NodaTime 2.2.4'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.6,Profile=Profile44', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Do I have to downgrade to .Net 4.5 or what options do I have?
Noda Time 2.x only supports the Target Framework Monikers netstandard1.3 and net45. There's no direct PCL support, although some environments that traditionally used PCLs now support .NET Standard.
The 1.x series supports PCLs via Profile328, which has a NuGet target of "portable-net4+sl50+win8+wpa81+wp8". For environments that don't yet support .NET Standard, trying the 1.x series is the best option.
Note that I'm expecting Noda Time 3.0 to probably target netstandard2.0, although I'll still keep the older versions up to date with respect to time zone data.
I installed the Achecker from http://www.atutor.ca/achecker/
and ran the guidelines to get a report.
Earlier we were doing the same with http://Achecker.ca
There are few guidelines are missing in the local version. They are not similar. Is there any difference and if yes is there a way to upgrade the techniques to latest on the local version.
The version from the Web site is the Achecker version 1.3 (25/11/2011).
See sourceforge history here:http://sourceforge.net/projects/achecker/files/achecker/
You can find on GitHub, a version of June 2014:
https://github.com/inclusive-design/AChecker
The Node.JS website says the current version is 0.10.26, but the git repo has much newer versions going up to 0.11.12.
Is there something wrong with the later versions, are they unstable?
Why does the website say 0.10.26 is the current version?
From the Node.js wiki:
Odd versions are unstable, even versions are stable. v0.2 and v0.4 are even/stable. v0.3 and v0.5 are odd/unstable. The current stable series is v0.10.x. The next stable series will be v0.12.x. The stable branch takes bug fixes only - it does not change the JavaScript API, addon API, nor ABI (you don't have to rebuild modules after upgrading node with-in a stable branch).
You should use stable versions for production. The web site displays prominently and gives links to download the latest stable verson.
However, if you are trying to stay ahead of the curve and prepare for the next and yet unreleased stable version, then testing against an unstable version makes sense. This is why the unstable versions are also available to developers.
I'd like to begin learning CUDA but I'm confused about the versions. The latest release of CUDA is 3 and I have the CUDA 3.0.1 driver on my system but in theory my graphics card only supports 1.0. Can I use the features of the later versions or I need to stick to the 1.0?
The latest public release is 3.2 but 4.0 is out in beta to registered developers. Compatibility is based on the features that the hardware supports. You can use the latest version of the SDK but will need to compile for the feature set supported by your card and not attempt to use SDK features that are not supported. You do this by setting the arch flag.
There's some explanation here:
Fermi Compatibility Guide - NVIDIA
CUDA toolkit versions (3.1, 3.2, 4.0) are different from the graphics card compute capability (1.0 / 1.1 for older geforce cards, 1.2 for many mobile cards, 1.3 for slightly old geforce, 2.0+ for the latest fermi architecture). All the toolkits work with all cuda capable graphics cards. Although the complete functionality may not be available, you can still write functional cuda code.