I recently updated my Android Studio to 0.3.6. My old projects weren't using Gradle, but I tried to start a new one, and I'm getting the following error:
The SDK directory 'C:\Users*gibberish*\AppData\Local\Android\android-studio\sdk' does not exist.
My user name is not in latin characters, and it seems it reads the path wrong, although I checked the local.properties file, and it is typed correctly, and in UTF-8 encoding. I tested with older versions (such as 0.3.2, which is current stable) and the problem does not exist.
I read about problems with the new gradle plugin etc, and since the project's files are created, maybe this is another gradle issue?
Should I just revert to the stable version?
If you're on Windows and your pathname has non-ISO-8859 characters in it, there's a known bug that will prevent Android Studio from dealing with it properly; see https://code.google.com/p/android/issues/detail?id=56102. This is actually a longstanding Java bug that will be pretty difficult for us to work around.
I'd recommend putting your projects in a path that doesn't include non-ISO-8859 characters.
In my Eclipse ADT setup, under the project root I added a file with name: local.properties
In that file, I have one line:
sdk.dir=/Users/my_username/tools/android-sdk-macosx
It solved the issue. I found the solution at Gradle Plugin User Guide
They have this note below. I did have ANDROID_HOME set, but was still getting the error until I added the properties file (.. not sure why?!)
Note: You will also need a local.properties file to set the location
of the SDK in the same way that the existing SDK requires, using the
sdk.dir property. Alternatively, you can set an environment variable
called ANDROID_HOME. There is no differences between the two methods,
you can use the one you prefer.
If you are on Windows you should first make sure your enviornment variables are set correctly.
create ANDROID_HOME if you don't have it, make sure it is set to C:\Users\USERNAME\AppData\Local\Android\Sdk.
No need for the local.properties file for me after that.
Related
After one of the recent upgrades of Android Studio and/or the Gradle plugin, I've noticed that a build.grade-e file is created after I edit a build.gradle file. The build.gradle-e file is a copy of the pre-edited copy of build.gradle and I assume it is simply a backup.
Trying to google this filename has been difficult since Google ignores the hyphen.
Since build.gradle-e seems to be a backup, I don't see a need to introduce it into my git repository.
Is is safe/good to add build.gradle-e to my .gitignore?
This is nothing that comes from plain gradle, so I suggest it is some sort of working copy used by the android studio. I definitely would add it to .gitignore. Even better it sounds like an issue in Android studio for me.
I have the following problem with my software in Visual C++.
I've set some Build Customization related to the file in the path: $(VCTargetsPAth)\BuildCustomizations\PROGNAME 4.2.targets
On a different pc I have a different version of the same file (for ex: PROGNAME 5.0.targets); when I open my VC++ project, I have to edit the *.vcxproj file in order to set manually the new version of targets.
Is there a method to avoid this problem and make the project available with different versions of targets file?
Thank you in advance.
You might be able to do it by referencing a short cut instead. Each machine has a short cut in a known location that refers to what ever you need to refer to.
I'm trying to create a setup project for a product that should be able to install itself alongside its own older version. I have tried to add [Version] to the default location of the application folder, but this doesn't seem to work. Namely, when I set this:
DefaultLocation: [ProgramFilesFolder][Manufacturer]\[ProductName]-x-[Version]-y
Setup totally ignores the Version variable, and suggests
C:\Program Files\<company>\<product>-x--y
as the default location. [Version] is set to <number>.<number>.<number> in the setup project properties.
What's wrong with me or with VS? How can I add versioning to my default location?
Answering my own question.
Apparently the correct variable to use in this case is [ProductVersion] and not [Version]. I have no idea how it is supposed to be known. I have figured it out by looking at the install logs, searching for the word "version", and trying what I've found.
I need to reference a project in a Xcode workspace by an environment variable. An Xcode workspace file might look like this:
<Workspace
version = "1.0">
<FileRef
location = "group:../../Some/Dir/SomeLibrary.xcodeproj">
</FileRef>
<FileRef
location = "group:SomeApp/SomeApp.xcodeproj">
</FileRef>
</Workspace>
I want the SomeLibrary project to be referenced by an environment variable, so that the workspace file and projects can be used in different developer environments (the lib project is shared between several different projects). Any ideas on how to do this? Is the XML-format documented somewhere?
Thanks! :)
In your XCode 4 Preferences, you'll see a "Locations" tab and in the "Source Trees" section you can put an environment-variable like location (which you can change from machine to machine). And you can use these settings to change paths for the libraries you're trying to include or reference in your projects.
It's not exactly the environment variable from the Terminal command line, but then again most people don't launch XCode from the Terminal and so you shouldn't expect to pick up your $PATH or other UNIX-style environment variables from double clicking on any app, much less the XCode IDE. It's a good alternative.
There's some more information in this related question and here's Apple's documentation on what they are and how to set them up (which is aimed at XCode 3 but the same concepts apply for XCode 4).
Let me know if I can provide more information, and I hope my answer helps!
I think I need to answer this myself. Based on my research it is not possible to use a dynamic location (environment variable, source tree, etc) on workspace projects.
Solution 1:
You CAN achieve what I'm trying to do using symlinks. In my current workspace I've created one application-project, and a project entry which points to a symlink on the local file system. This way one can switch projects and have dynamic locations for the library-projects. I'm not sure if XCode treated this link properly when adding, so I manually added the project entry like this:
<FileRef
location = "group:Libraries/SomeLibrary/SomeLibrary.xcodeproj">
</FileRef>
Where SomeLibrary (IMPORTANT: The folder SomeLibrary need to be the symlink, or else XCode wont be able to find the project contents) is a symlink to my static library project somewhere else on the local file system. This way, developers can have different paths to the library, and one can easily switch versions when needed.
Solution 2:
Adding a static library project as a subproject and using cross-reference. For sub-projects, one can use Source Tree and use dynamic locations.
I haven't tested these solutions widely, so I'll come back with a reply after using it for a while.
I have a VB6 project, when I came to check in changes to the VB6 project file I noticed that the Visual Studio 6 IDE had automatically inserted the following line:
VersionCompatible32="1"
What does this mean?
As an aside: Is there a good resource to help me make sense of the VBP file?
The VersionCompatible32 value in the VBP file seems to be part of the binary compatibility settings of an ActiveX project, maybe the typelib it needs to be compatible with (there can be several in a library).
When my project is set to no, or just project compatibility, this value is removed.
Note that the compatibility setting itself is stored in the CompatibleMode value.
First of all, I don't think it is a good idea to edit the VBP file manually. As far as I know, VersionCompatible32 is a hint about the VB(A) version that was used to save this file, probably for newer versions to recognize changes in the file format.