Unable to find ant program - ant

I am an experienced (but retired) Windows software developer, with more years experience than I care to admit, developing in C++, C#, VB and Java. I therefore decided to have a crack at Android development. My development machine is a Windows 7 box. My IDE of choice would be Microsoft Visual Studio but, for now, I am happy doing hand editing and launching tools from the command line.
I started by downloading the Android SDK and various additional items it suggested. I then started working my way through the tutorial at developer.android.com/training/basics/firstapp. Android list targets gave me a couple of choices (Android 4.2.2 and Google APIs:17). I then did Android create project from the command line and that appeared to do its stuff, creating MyFirstApp in my development folder. I then ran Android avd and created an emulator. I also added the android SDK's tools and platform-tools to my path. So far so good.
I fell at the next hurdle. The tutorial told me to change to the root folder of my project and run ant debug. At this point, Windows reports:
'ant' is not recognized as an internal or external command,
operable program or batch file.
I've searched around for ant.exe without success. Did I miss installing something or did I miss a vital step in the set-up? Any advice for this very green newbie would be greatly appreciated.

There is no ant.exe. Only ant.bat. Ant is a Java build tool.
If it comes with the Android SDK, make sure its bin directory is in your PATH environment variable. Otherwise, download it (from [http://ant.apache.org][1]), and follow the installation instructions on the web site.
Normally, simply unzipping it, putting its bin directory in the PATH envieonment variable, and setting a JAVA_HOME environment variable that points to your preferred JDK directory is sufficient.

Related

How to build a Windows driver development kit 7 on 10

I am trying to build a Windows driver for a piece of hardware I am using. The build notes seem dated as they specify using DDK for Win7. I have Windows kit version 10. Are these the same thing just later version? The instructions then state to open a DDK command window environment then use "build -ceZ" in the dir where the files are located. Does v10 have this console and if so where can I find it? Thanks
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/wdk-and-visual-studio-build-environment
"The Windows Driver Kit (WDK) 8.1 and WDK 8 introduced a major change
to the environment that you use to build a driver. The WDK no longer
uses Build.exe. The WDK build environment for drivers uses MSBuild.exe
and is fully integrated with the Visual Studio development
environment. This means that source files, makefile.inc, makefile.new
and other related build files present in the previous version of the
WDK are no longer used. The WDK now enables you to create, edit,
build, test, and deploy a driver through Visual Studio. The purpose of
this document is to provide information to help users familiar with
previous WDKs in getting started with the WDK 8.1 and WDK 8."
If you want to build the driver as is then you will need to install the Windows 7.1 DDK and build it using its tools.
https://en.wikipedia.org/wiki/Windows_Driver_Kit
https://www.microsoft.com/en-gb/download/details.aspx?id=11800
You are allowed to install different versions of the DDK on the same machine.
You might find it tricky to install DDK 7.1 on Windows 10 though, try and use this to get around any problem install.
https://stackoverflow.com/questions/32091593/cannot-install-windows-sdk-7-1-on-windows-10#:~:text=If%20you%20continue%20with%20Setup,187668%20and%20then%20rerun%20Setup.
Then it's just a case of "choosing the 7.1 ddk environment (32bit or 64bit)" so that it's tools are accessible/used when "building" your driver.
Look in your startmenu at "StartMenu -> Windows Driver Kits -> WDK XXXX -> Build Environments" to find a command prompt to open.
If you can't/don't want to install the DDK 7.1 and a WDK8+ version of your driver project isn't available then it may be possible to convert the driver from using the older "makefile" into new msbuild way of building, but might be fiddly.
https://community.osr.com/discussion/289475/build-exe-to-msbuild-exe-migration-advice
"If you go into VS you should be able to create a WDK driver project.
It will give you a solution with (I think) one C file filled with
everything necessary to make a driver which does nothing. But, most
importantly, it will generate an XML file that MSBuild will accept.
The XML format is not documented. After you have this XML file you
should be able to figure out how to add your files to it by hand, but
you could move the existing driver files to the project using the GUI.
That may be easiest."

Instructions for how to lay out the Mac OS X and Linux versions of Electron apps?

I've just spent a very long time looking through everything on https://electron.atom.io/docs/ but I cannot find any mention of how to put the files for Mac and Linux. Only Windows, which I already have set up.
I remember that NW.js had such instructions, which I followed in the past, but it's obviously too ridiculous to accept that I should have to look at a competitor's manual to figure out how to distribute Electron apps.
I remember that at both Linux and Mac had some very fancy/weird packaging need, very unlike Windows.
I would recommend looking into electron-builder which would help you with generating packages for all of the mentioned systems (with auto-update and other goodies).
You can also take a look at electron-boilerplate to see how it can be nicely implemented (this boilerplate has a release command that allows you to generate packages).
For the mac version you can use electron packager to generate a .app file then you can use appdmg to generate a .dmg
For the linux version you can use electron packager to generate a executable although it comes with lots of other files.
I've tried electron-installer-debian but I couldn't install the output .deb

Visual Studio iOS deployment fails because "The edge module has not been pre-compiled"

I am trying to deploy a HTML/CSS/JS Apache Cordova application from a windows machine to a Mac. I believe they are communicating properly through the remotebuild agent but when I attempt to build a blank project to deploy on the Mac this error is thrown at the very beginning of the build:
MDAVSCLI : error : The edge module has not been pre-compiled for node.js version v4.1.1. You must build a custom version of edge.node. Please refer to https://github.com/tjanczuk/edge for building instructions.
I have followed the link and have searched for the solution as to how to fix this error but the link does not seem to apply to what I am doing at all. I am not using any node.js functions in my code so I am confused as to why this error is occuring. I am only trying to build a nearly blank HTML page and I still get the error regardless of how simple I make the page.
How can I go about fixing this solution? what is the best way to get rid of this error or to as the error suggests pre-compile edge to work with node.js version 4.1.1?
There is an issue with Cordova 5.3.1 and Node v4.
https://github.com/Microsoft/cordova-docs/blob/master/articles/known-issues/known-issues-ios.md#building-for-ios-hangs-when-nodejs-v40-is-installed
I fixed by uninstalling Node v4.1.1 and installing Node v0.12.7
https://nodejs.org/en/download/releases/
#Dustin,
you have a misconception about how Cordova works. You say you want to deploy to a Mac, but I think you mean iOS. If so, you should read:
What's needed for iOS Development?
https://groups.google.com/forum/?fromgroups=#!topic/phonegap/bf1Hgkel3W4
I Quote
The short and sweet of it is as follows:
You need OS X + Xcode
You need several iDevices
You need $99/year for Apple Developer program (which you've already indicated is not a problem)
All of the above = cost-of-doing-business.
If you read the entire thread (especially the part from Kerri Shotz), you will get more information and more options.
Best of Luck
After losing a fair bit of hope and following a lot of posts, blogs and bug work-arounds with no luck I decided to click on the 'Run Dependency Checker' button in Visual Studio - Tools -> Options -> Tools For Apache Cordova -> Cordov Tools. This checker told me that Joyent Node.js wast installed. I did have node.js and npm set up on the latest version, im not sure what the difference is.
I went through the process of modifying the VS installation (change or remove a program) and sure enough Joyent Node.js wasnt checked. I cheked it and it went through the process of installing.
My VS installation now looks like the below and my project is building without:
MDAVSCLI : error : The edge module has not been pre-compiled for node.js version v4.1.1

Webapplication.targets missing when building a MVC4 project in MonoDevelop on OS X 10.7.4

I am trying to build a test MVC4 project on OS X 10.7.4 using Mono 2.10.9. I created a new empty MVC4 web application in Visual Studio used git to transfer the source code from Windows to Mac OS X. I then ran xbuild for .nuget package restore, but when I build in monodevelop I get a weird error:
/Users/tamasnagy/Developer/Spellbound/Spellbound/Spellbound.csproj: Error: /Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/xbuild/Microsoft/VisualStudio/v10.0/WebApplications/Microsoft.WebApplication.targets: Project file could not be imported, it was being imported by /Users/tamasnagy/Developer/Spellbound/Spellbound/Spellbound.csproj: Imported project: "/Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/xbuild/Microsoft/VisualStudio/v10.0/WebApplications/Microsoft.WebApplication.targets" does not exist. (Spellbound)
What could this mean? This also happens when I simply create a new MVC project in MonoDevelop and press build. Any ideas?
Create a symlink:
cd /usr/lib/mono/xbuild/Microsoft/VisualStudio/v9.0
ln -s v9.0 v10.0
I have the same exact ubuntu 12.04 distro on two different computers and could not figure out why mono would compile on one computer and not the other. But oh well, symlink solved the problem.
Change your csproj file to import v9.0, as so...
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
Mono's MSBuild implementation (xbuild) does not have an implementation of the targets for ASP.NET projects.
You might be able to build in MonoDevelop. Make sure you have the experimental xbuild integration turned off in MonoDevelop preferences.
I know this is an old question, but it came up when searching for how to use WebApplications.targets on OSX, so it's still worth answering. With the current version of Mono (5.x), Webapplication.targets is included, so now all you have to do, is to set the VSToolsPath, and everything should just work.
If you are using standard bash shell, the .profile file is the place to put it:
export VSToolsPath=/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild/Microsoft/VisualStudio/v15.0/

How do I run D3D9 programs (that have already been compiled) on a machine without the SDK?

I have a simple 3D application programmed in C++ and D3D9 using MSVC++ 2008 Express. Some weeks ago, I had to format my hard disk, so the DirectX SDK is not currently installed.
However, I found that the exe file that I found in my "Debug" folder for the project does not run. The error it gives is:
"This application has failed to start because d3dx9d_38.dll was not found. Re-installing the application may fix this problem."
Of course, it worked after I installed the SDK. Then I compiled a "release build" thinking that that was the solution. Then I uninstalled the SDK and tried to run the .exe file.
Still gave me the error.
So how does one make such .exe files run on machines without the SDK?
I think you cannot run the app without the SDK. See XBMC, which requires the SDK to run.
However, you could try simply placing the required dll file from your SDK in the same directory as the executable.
I followed the solution as stated here.
I copied the d3dx9_38.dll file into my Release folder. It still didn't work. However, I renamed the dll file to "d3dx9d_38.dll. Then it worked.
Wondering why I had to rename to the debug version of the file even though it was a RELEASE build...

Resources