We have renewed the "Aspose.Cells.lic" and "Aspose.Words.lic"
the steps that we did:
we have downloaded the files.
we replaced the new files with the old ones, but we noticed that the naming of the new files is different, before we had "Aspose.Cells.lic" and "Aspose.Words.lic" , but now we got files with "Java" and the license version is different
This is the message that we got when we applied the files:
The signature is invalid.java.lang.IllegalStateException: The signature is invalid.
the steps that we did:
we have downloaded the files.
we replaced the new files with the old ones, but we noticed that the naming of the new files is different, before we had "Aspose.Cells.lic" and "Aspose.Words.lic" , but now we got files with "Java" and the license version is different
Please note, new licenses are signed with SHA256 but older ones were signed with SHA1. Either you may use your older license(s) with the old versions of Aspose libraries and newer license(s) with the new versions of Aspose. Or you may contact relevant team to get updated licenses (e.g. signed with sha1) which can work with both newer and older versions.
PS. I am working as Support developer/Evangelist at Aspose.
Related
I have a legacy application using proto2 with libprotobuf2.x. There is another application application that I would like this application to talk to with proto3.
I checked on possible solutions and the discussion in this thread
says that libprotobuf3.x provides compatibility with proto2.
Does this mean that I can use the same proto(with proto2) and the same code stubs pb.h/pb.cpp generated for proto2 and just link my legacy application with libprotobuf3.x instead and it would work like a charm?
I don't want to update legacy protos to proto3 as it might require major refactoring in the legacy code.
No, you can't link .pb.* files generated with protoc 2.0 against libprotobuf 3.0.
Just like with any shared library, an increment in the major version number means a breaking API change.
Compatibility with proto2 means that Proto 2 syntax is supported (syntax = "proto2"). Also proto3 is binary-compatible with proto2 on the wire.
I don't want to update legacy protos to proto3 as it might require major refactoring in the legacy code.
Chances are, if you re-generate your .pb files with protoc 3 and recompile, it'll work without refactoring (the default syntax is still proto2).
I need to update the OWASP AntiSamy jar file which is located at ColdFusion11\cfusion\lib
The file currently in there is antisamy-1.4.4.jar but I want to update this to the latest version which is antisamy-1.5.3.jar which I have downloaded from OWASP and placed in the cfusion\lib folder.
Does anyone know how I can tell ColdFusion to use the latest version of the file? Is the path to the file in some configuration file anywhere?
In CF Administrator I can see both the old file and new file under 'Settings Summary' but how do I know which one its using to power the GetSafeHTML function?
I want to update this to the latest version
AFAIK, there is no list of individual files. At least not for the "core" jar files used by the CF Server. It simply checks certain directories like {cf_root}\lib, web-inf\lib, etcetera and loads any *.jar files it finds.
If you want CF to use a different version for core tags and functions, you must replace the existing jar file with the new one. The actual jar file ame does not matter. What is important is having only a single version of the library in the CF class path. Otherwise, CF will simply use the first version it finds.
You can also try placing the new jar file in the jvm's lib/ext directory. IIRC, those jars should take precedence over the ones in {cf_root}\lib.
NB: Since you are replacing/overriding the version used by CF, you should do some testing to verify the new version of the library is backward compatible and that replacing it does not break anything. As noted in the comments below, there is always a risk of problems when messing with CF's built in jar files...
How would I write nodejs addon which would support all versions (atleast all stable versions > 0.10.6) of nodejs. For example, one version would have String::Utf8Value name(args[0]); where as another would have node::Utf8Value name(args[0]);. This is just an example but I have many scenarios where there will be different code for different versions of nodejs.
As far as I know this could be achieved in following ways.
Defining pre-processor to check which version and compile code accordingly.
if defined()//Not sure what exactly have to checked
include <nameser.h>
else
include <arpa/nameser.h>
endif
If this is the best option(which I don't think) even if multiple places pre-processor as to be added and code looks ugly, how would I achieve this. Meaning how would I check which version of NodeJS inside C/CPP addon.
Having separate file for each version and defining conditions inside binding.gyp to compile specific file based on nodejs version. If this is the best option, which variable I can refer to check the nodejs version.
Having tags while publishing npm package so that user can install for his specific nodejs version. Tag a published version. Although user has to check for the nodejs, non technical person won't be executing this, so shouldn't be a problem. The only problem I am seeing with this approach is versioning. Example, If there is a fix which has to applied for multiple tags, then, for every tag publish I have to specify different version (Not sure though).
Any other way I can achieve this which I am not aware of, if any the above options is not the good option to go with ?
From my understanding reading this thread from several years ago, somebody once got Protocol Buffers working with Codegear C++ Builder 2007
https://groups.google.com/forum/?fromgroups=#!topic/protobuf/YapO_DqFVvc
The author of the above Builder 2007 version of protobuf uploaded it to a 3rd party URL, however the link to it seems to be long dead, and judging by the discussion and the current state of Protocol Buffers 2.5.0 the fix/change has never been forked from protobuf or merged into the trunk.
Updated:
When using generated code from protoc.exe (2.5.0) for either of the example .proto files, C++ Builder 2007 complains about a multitude of problems, including "duplicate entries" for names in the google::internal namespace (such as google::internal::kEmptyString - it also complains about the std::hash based containers and that memset is an unrecognised symbol.
It took me several days to arrive at a solution, but here's how I managed to get it working in Codegear 2007:
Obtain the C++ Builder version of protobuf https://github.com/saadware/protobuf-cppbuilder - this is based on 2.4.1, so it is a little outdated, but I would guess that it's possible to merge the C++ builder changes into 2.5.0 (or whatever the latest version is). The C++ Builder version of protobuf is for Builder 2009, but it fixes various problems with std::hash, so it's a better starting point than Google's release.
Take a copy of the following .cc files in the ./src/google/protobuf folder and change them to a .cpp extension. There seems to be an issue with the .cbproj format which doesn't like .cc (You will need to add all of these files into your Codegear 2007 .cbproj - these are the files required for libprotobuf-lite).
extension_set.cpp
generated_message_util.cpp
message_lite.cpp
repeated_field.cpp
wire_format_lite.cpp
stubs\common.cpp
stubs\once.cpp
io\coded_stream.cpp
io\zero_copy_stream.cpp
io\zero_copy_stream_impl_lite.cpp
As per the thread by 'Dazza' use find-and-replace-in-files (e.g. Notepad++) to rename the google::internal namespace. Note that a case-sensitive find/replace is required because there are occurrences where the name 'Internal' is used for other things. For this step I followed Dazza's suggestion of changing it to google::internals. (Note - this is both for the libprotobuf-lite and for the strings used to make the generated code)
In the generated code strings, search for all occurrences of memset and change them to std::memset (This is primarily for the code generator lib; libprotoc. If you don't do this, every time you re-generate your .proto bindings, C++ builder will be unable to identify memset.
Build protoc.exe using Visual Studio (I couldn't get Protoc.exe to build in Builder, but that shouldn't matter anyway, the code generator only needs to be built once)
Modify the example .proto files use the lite runtime;
option optimise_for = LITE_RUNTIME. Note - reflection capabilities are not available with this option switched on.
Run protoc.exe on your .proto file with --cpp_out. The output file will have a .cc extension - you will need to rename this to .cpp
Add your generated files to your project and build.
(Note- there are still a few warnings outstanding - one complaining about a superfluous & taking the address of a function, and a few others complaining about signed/unsigned comparisons - but at least it builds and seems to work)
I have some C++ code which uses boost's GIL image library, and wants to write files using boost::gil::png_write_view from boost/gil/extension/io/png_io.hpp. That header itself includes png.h, and of course results on a link dependency.
On Debian it compiles and links fine. If it did complain about anything missing, the necessary headers and libs would be a few seconds away via an aptitude install libpng-dev.
On Windows (VisualStudio 2008 on XP64), I'm having to face the idea that it looks like I'll have to build libpng from source (and so also its zlib dependency) myself. If there's an obvious packaging already out there, I'm not seeing it. Can anyone enlighten me if there is such a useful resource anywhere ?
Libpng's own packaging itself seems to supply project files for vc6 and VC7.1 (VS2003). And more recent releases also come with VC10 project files. But nothing for VC8(VS2005) or VC9(VS2008). However there are instructions here (which I've yet to try) which describe building for 2008 after running the 7.1 project files through the conversion wizard.
I did initally try the GnuWin32 build of libpng, but (apart from being 32 bit only) it crashed in a libpng call to fwrite when passed a FILE* from VS2008's CRT. libpng's own documentation has something to say about this and the perils of mixing different versions of MSVC but their suggested workround is only relevant to direct libpng users (and I'm using it via boost GIL).
Update: the converted project files do work pretty well (maybe some minor obvious fixups). By far the biggest part of the job was creating the 64bit builds; the original and converted project files don't include any such configuration and while visual studio will have a go at creating them, there was a fair amount of config dialog editing to get consistent folder/file names etc.