Good day!
Can you tell me how update the org.json:json component to a newer version? Current version - 20171018. Newer version - 20220924.
Assuming it's 100% backwards compatible you can just download the new jar (e.g. from here) and replace the old one with the new one in the broker distribution.
In ActiveMQ Artemis 2.27.1 json-20171018.jar is in the <ARTEMIS_HOME>/web/console.war archive in the /WEB-INF/lib directory.
Related
downloading new version of npgsql i could See is not compiled old mono.security dll file. Is Not needed in newest version? I have not to ad any reference to this library if i use 3x version?
Thanks.
You're correct - Mono.Security.dll is no longer needed in Npgsql 3.x. You don't need to add any reference to any external library in order to use Npgsql 3.x.
The Scala website says:
For historical and testing purposes, we also keep an archive of
previous releases (currently since version 2.5). Prior versions of
Scala, from 0.9.x to 2.4.x, have been archived offline.
Is there any way to get these versions? The source code is available in the git repo, but binaries would be nice.
EDIT:
I found some old versions at archive.org, but the oldest that I could get was 1.1.1.3 from http://web.archive.org/web/20040603140225/http://scala.epfl.ch/downloads/index.html
It turns out, if one looks hard enough, everything from 1.0.0-b4 can be found on archive.org. Unfortunately, some version in between are nowhere to be found, for example 2.3.x and 2.0.x. The question remains why they aren't published on http://scala-lang.org.
How can I get the source code for Arjuna/JBossTM that matches my JBoss version?
More specifically, is there a way to reliably identify the version of a library that is distributed with JBoss 5.1.0?
The options I've tried so far:
opening the manifest file of jbossjts.jar which gives me 5.1.0
opening the file jar-versions.xml, but that also gives me 5.1.0
From the look of the tags JBossTM doesn't go beyond 4.12.0 so I think I can be pretty sure in saying that 5.1.0 is the same 5.1.0 as JBoss itself.
Is there a way to reliably get the correct version of the source code for this (or any other) library? It seems to me that sometimes the manifest contains the version of the library, sometimes the version of the server, which isn't very helpful.
Thanks in advance
Rich
Further to this, I think I have found the information by going into the JBoss 5.1.0 release notes where one of the Component Upgrade bugs is jira.jboss.org/browse/JBAS-6851 - Update to transactions 4.6.1.GA
I have a .net (2.0) winforms application that I need to upgrade on client machines. At the moment this is done by incrementing the Assembly Version and File Version on all of the projects and incrementing the version on the Installer project in VS2008.
The application now makes use of Isolated Storage to save some user settings in an XML file (grid layouts etc...).
The problem I am now facing is that if I increment all the version numbers, the application has a new location for its Isolated Storage, because the File Version has changed. With a new location for isolated storage, all the settings have effectively been lost.
When upgrading does Windows installer replace the dlls based on the File Version or the Assembly Version?
If it is the Assembly Version then all I'd have to do is not increment the File Version.
Some good reading and discussion here:
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/6ed4d384-f6e9-42ee-b485-0bf40d0abd65/
To answer your question, though, I believe that MSI's respect FileVersion primarily:
File Versioning Rules
I want to create an MSI installer containing three apps. I will be releasing frequent updates to each app as I work through the list of feature requests and do bug fixes. The three apps are currently at versions 1.6.3, 1.6.12 and 1.8.1 respectively.
I was wondering what you guys can recommend for the version of the package. Should I:
Make the package version independent of the versions of the individual apps ?
Change the apps so they always have the same version as each other ?
Some other suggestion ?
Modify the package version each time the version of one of the apps changes. Then, you can look at the package version and know exactly which version of each app was being used.
Example:
Main version 1.4.1 has (1.6.3, 1.6.12, 1.8.1)
Main version 1.4.2 has (1.6.3, 1.6.13, 1.8.1)
Main version 1.5.0 has (1.7.0, 1.6.13, 1.8.2)
Main version 2.0.0 has (1.7.0, 1.6.14, 2.0.0)
So, if you're doing a minor version upgrade to one of your apps, the main application also goes up by a minor version number. Major changes to a sub-app result in the main app also getting a major version number change.