I'm trying to setup a project which contains a package called Autorest. This was installed via NuGet and inside the packages folder of the project is an executable tool Autorest.exe. Unfortunetly, this version is for 64-bit and I can't run the tool to get my API from my web service. What can i do?
Related
I am using a tool (tagui) to automate the web. The dependency for this are the source file which actually contains the script for the automation, a jdk package, php and python.
Trying to make this as a debian package so that it can be used as an executable file and shared among everyone.
I am having a set of eclipse plug-ins developed for both Linux and Windows environment. It includes platform dependent fragment plug-ins for Linux and Windows built using an update site project. Since they are only plugins I don't build using eclipse product definition.
Currently I have to build the update site separately for Linux and Windows. But I want to build for both Linux and Windows at the same time either in Linux or Windows. Is there any solution for this?
I was given A Visual Studio project written that has a reference to the dll in the Windows GAC
Microsoft.Practices.Unity.dll 1.2.0.0
which I don't have installed on my machine
The same dll is not anywhere in the project directory.
I downloaded Enterprise Library V6 but the dll is version 3.0.1304.0
I was able to locate other dll versions
2.0.505.0
2.0.414.0
I change the references in the projects from 1.2.0.0 to a later version but the code isn't backward compatible so I need the exact dll version.
Where do I get this dll?
I googled for it but one I got is a virus, the other was 2.0.505.0
You can find it in the Unity Application Block 1.2:
https://www.microsoft.com/en-us/download/details.aspx?id=701
Once installed, the file is located under Microsoft Unity Application Block 1.2\Bin.
I decided to install all the Enterprise Library Installers to find which one contained that version.
The version it was in was Enterprise Library 4.1. I downloaded it and extracted it to a folder and was able to obtain the dll.
Link
We were using AEM 6.1 quickstart on Windows machine with Java 1.8.
To be consistent with other teams, we had to downgrade our Java version to 1.7.0_79 , after we uninstalled Java 8 and rest the JAVA_HOME and PATH variable to reflect the new (downgraded) version of Java and ran AEM using "crx-quickstart.jar" file, AEM started properly but the default startup page does not load and shows this exception:
java.lang.UnsupportedClassVersionError: org/apache/jsp/libs/granite/core/components/login/login_jsp : Unsupported major.minor version 52.0
RequestURI=/libs/granite/core/content/login.html
Servlet= /libs/granite/core/components/login/login.jsp
ApacheSling/2.4 (jetty/9.2.9.v20150224, Java HotSpot(TM) 64-Bit Server VM 1.7.0_79, Windows 7 6.1 amd64)
One of the solution that worked for us is to rename or delete the "crx-quickstart" folder.. and starting AEM, would work as AEM will recompile everything using the correct version of Java and everything works as expected. But is there any other way.. not to rename/delete the crx-quickstart folder?
Here's a more detailed explanation of the solution:
Symptom: After you upgrade or downgrade a version of Java on your machine, and see that pages are not loading on AEM, not even the main login page.
What causes this:
When AEM is starting up, it compiles java/jsp files using the version of Java is installed on the pc. When there is a change in the version of Java, the new files should be compiled by the installed version and all references must be updated but there is an issue on AEM 6.1 (this maybe fixed in Service Packs).
Resolution:
NOTE: Please backup your AEM instance before doing this
Go to localhost:4502/system/console/configMgr
If the page opens, login as "admin"
Go to Menu > OSGI > Bundles [http://localhost:4502/system/console/bundles]
Find this "Apache Sling Commons FileSystem ClassLoader (org.apache.sling.commons.fsclassloader)" and note the BundleID (it
is 218 for me)
STOP AEM
On Windows Explorer go to this path where your AEM is installed.. $path\aem-61-author\crx-quickstart\launchpad\felix\bundle218\data
Delete the classes folder under it.
Restart AEM.. this should fix the issue.
If the page above does not open,
(assuming the bundle-id is 218)
STOP AEM
On Windows Explorer go to this path where your AEM is installed.. __
$path\aem-61-author\crx-quickstart\launchpad\felix\bundle218\data
__
Delete the classes folder under it.
Restart AEM.. this should fix the issue.
To avoid downgrading your java-version, one work around is to apply Service Pack 2 when you first time install CQ6.1.
First, download your SP2 from adobe package share or copy from other machine. Then unpack your cq jar file and copy your SP2 zip file to crx-quickstart/install folder then install.
The detail step should be like below
java -jar cq5-author-<port>.jar -unpack -v
cp SP2.zip crx-quickstart/install
java -jar cq5-author-<port>.jar
Once again, the Service Pack 2 must be applied when first time install.
I've downloaded the VisualVM source and am trying to compile the Glassfish plugin using Netbeans 7.01. Doing so results in the following error:
C:\source\visualvm\trunk\plugins\glassfish\nbproject\build-impl.xml:48: You must define 'nbplatform.VisualVM_100609-dd12ae64a19c.harness.dir'
That lead me to the project settings which shows the platform as "Netbeans IDE...". The drop down box is grayed out so I can't select the correct platform.
Yet, on my hello world VisualVM plugin I can set the platform to the appropriate platform and it runs great.
To try and resolve this I've tried creating platform.properties file and putting it in the nbproject folder with the following entries. However, this doesn't seem to be working
harness.dir=mypath/visualvm/visualvm_13
and
nbplatform.VisualVM_100609-dd12ae64a19c.harness.dir=mypath/visualvm/visualvm_13
Any suggestions.
Glassfish plugin is part of 'plugins' NetBeans modules suite. All modules from a Modules suite has to be build against the same version of NetBeans platform application (in our case VisualVM). This means that you can change the NetBeans Platform for the whole suite, go to the properties of the 'plugins' suite a change the platform there.
In order to build the VisualVM and it's associated plugins you must download the NetBeans platform and profiler binaries that are available on the VisualVM website's build guide section.
For example, to build the 1.3.2 release you would go to this section and download the NetBeans 6.9.1 platform and profiler binaries available through the link located on that page. The link I've provided also gives you instructions for obtaining the proper VisualVM sources from the repository and building VisualVM and it's plugins. For example, the sources for the 1.3.2 release can be checked out using the following url:
https://svn.java.net/svn/visualvm~svn/branches/release132
And once you've completed the checkout and extracted the NetBeans platform binaries (downloaded from the above link) into the
release132/visualvm directory, you can build the entire application and it's plugins by running ant build from the release32/plugins directory.
I successfully completed this entire process and can verify that the instructions work for 1.3.2. However, the instructions for building the trunk did not result in a successful build due to at least one missing dependency.
What the error that you were seeing was telling you was that the NetBeans platform's build harness could not be located. The harness is included in the downloadable binary and once you've extracted it into the release32/visualvm directory the values that are in the project.properties file will once again be valid. This is of course a good example of why you should keep everything needed to successfully reproduce a build in your repository!