any one know how can I get current path of eclipse workspace programmatically. Since this path changes in every computer I want to get this thing programmatically and dynamically. It should return a string and it should be like ersin/projects/proj/my_work_space_name.
by the way this code didnt work for me:
ResourcesPlugin.getWorkspace().getRoot().getLocation().toString()
it gives ersin/projects/proj/runtime-EclipseApplication whereas it should be ersin/projects/proj/my_work_space_name.
It looks like you're getting that value because you're running a test environment for debugging a plugin. When you do that, you're effectively running a different workspace and that's why you're getting the root location of that workspace. Should you get to the point where you run that plugin in your original development workspace, you'll get the value you expect.
In short, you are getting the current path of the eclipse workspace.
So if you're trying to debug a plugin that searches the workspace, you'll need to add projects to your test workspace so that the search can take place there.
Related
I have an Android App and need a JSON configuration file for AAD B2C in the raw directory which is called by like this:
PublicClientApplication.createMultipleAccountPublicClientApplication(activity.getApplicationContext(),
R.raw.auth_config_multiple_account,...)
I need a R.raw.auth_config_multiple_account for each buildType (and possibly flavor). Let's just assume I need a dev, test, prod. I read this article on providing alternate resources and this one for Configure build types, but I don't know exactly how this is supposed to work.
I assumed it might be a subdirectory in raw which is named for the buildType, but that does not seem to be the case. Does anybody have a simple example of this?
Also which buildType is used when you press play on Android Studio and run the app in the emulator?
I figured it out in case anybody else has questions around this. This article and this documentation helped.
I went into the project view in Project explorer, created a debug directory (to match my debug buildType in the build.gradle) in the src directory (making it a peer of main, test and androidTest), created a res directory under the new debug directory and a raw directory under the new res directory. I copied the auth_config_multiple_account.json file into it and altered the configuration to test it. All worked ok.
I'm working on 2 different machines (home vs. work) and transfer the code via GitHub, which works nice, but I just ran into a machine dependency when I added this code to the gradle.properties file to fix a vexing OAuth issue for google sheets:
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_131
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_77
Now I have to toggle between the 2 lines to get Gradle to compile. Need to check if I still need it (since I got the keystore files etc. sorted out), but I also wonder whether there is an easy solution to make this work (e.g. something like ifdef).
Obviously, I could just change the directory name in one of the machines I guess, but still curious how to solve this within Studio.
Lets start with a quote from the Gradle docs:
org.gradle.java.home
Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, jdk is safer. A reasonable default is used if the setting is unspecified.
So, by default, you should not need this project property (thats what they are called in Gradle).
However, there can be reasons, that you need to specify the Java directory. For this specific project property, you can follow Ray Tayeks advice and use the JAVA_HOME environment variable (on both systems). But there is also another approach, which can be used for any project property (and also for so-called system properties):
gradle.properties files can be located at different locations of the file system. Your files are located in the project directory and, therefor, they are included in your VCS. You can use them / it for project-related properties. An additional location is in the Gradle user home directory, which is by default the .gradle folder in your personal folder. This folder is not under version control, so simply define the property there.
try removing the line from the properties file. if that fails, try setting JAVA_HOME on each machine.
there are a lot of related questions.
you might try asking on the gradle forums.
Using TFS 2013 It is a simple matter to generate debug symbols as part of the build process by entering a location into the ‘Path to publish symbols’ field of the build definition. Unfortunately I can’t use any of the TFS build environment variables to specify the drop location for the symbols in the ‘Path to publish symbols’ field because symbol publishing takes place after the build is done and those variables are apparently no longer in scope. So I specified a Debug folder in a fixed location and was going to move it to the desired location with the PostBuild script. Even that does not work because the symbols are not yet present when the postbuild script runs. The order of events is (roughly):
1. Run prebuild script
2. Build
3. Run postbuild script
4. Tests
5. Generate symbols
It looks like this is typically accomplished with yet another server… a Symbols Server. Is that what everyone does?
I notice that the information to determine the proper location to save the files (for me anyway) can easily be found using information in ..\000Admin\server.txt. Using that info I could have the postbuild script wait (say… up to an hour) for the symbols to appear (they should be there in a minute). Then move the Debug folder from the fixed location to the proper location. Is there a better way?
Thanks.
The symbol server / symbol share is a separate thing from the drop location. It's structured in a specific way the Debugger understands and allows one to debug an application without having to ship the .pdb files with the application.
Since you may want to provide other parties access to your symbol server (similar to how Microsoft allows access to their symbol servers for most of the .NET framework), then you can simply tell them the location and optionally the credentials needed to access them.
The symbol share is not really meant for human consumption, it's all built up with GUIDs and hashes so that the debugger can find its way around easily and quickly. It's also structured so that multiple versions of the same symbol are stored side-by-side.
Especially that last part, storing different assemblies and different versions side by side in the same location, is why you should not try to inject project names or versions into the symbol share location. That's for the debugger to figure out.
Just to be clear, it doesn't have to live on a different server, the only thing required is that you enter a path to a share, it can even be a sub-folder of that share. so sometimes you see configurations like:
\\tfs\symbols\
\\tfs\builds\
Or
\\tfs\artifacts\symbols
\\tfs\artifacts\drops
But indeed, you could drop your symbols to a completely different server altogether:
\\tfs\builds
\\corporate\symbols
Or you could configure multiple distinct computer names for one system (or use multiple DNS records) and actually have the same server listen to:
\\tfs-symbols\share
\\tfs-builds\share
Or even register the shares at the Active Directory level, allowing you to just use
\tfs-symbols\
\tfs-builds\
What you choose is all up to you, but make sure that the two paths of symbols and builds are eventually unique.
Just learning about workspaces in TFS/Visual Studio 2012. I am testing using a Dev Branch and a Release Branch. I have setup workspaces that map to each of these branches from the server to the local folders.
Now I was assuming, and maybe incorrectly, that when I changed the current WorkSpace via Source Control Explorer, that since the workspace knows the mappings, it would then switch my Solution Explorer to show the local folder files associated with that workspace. This is not the case. Again, I was thinking it would act like FileZilla when you choose a site bookmark, that it then knows to connect to the server side code and then the corresponding local code....
So how do you actually access the local code in the Dev branch and then switch to the Release branch local code? Do you just have to close the Dev solution, then open the Release solution?
I see that this works, but it is confusing to know which version you are working with as the solution name will be the same when it is displayed in the Solution Explorer. You have to maybe r-click and view the properties of the file paths to see which actual version (Dev or Release) that you have opened. Same issue when opening VS and it lists the same solution name under the Recent section...you have to hover over it to see which version you want to open...all in all, it just seems like there is a decent chance that you could confuse the 2 and start coding in Release when you mean to code in Dev... I know you have to be careful, but this definitely doesn't help.
It would be nice, and maybe I missing this, if from when you first open VS that it would give you the option to open a WORKSPACE instead of a solution/project. At least that way, you can name your workspaces to be meaningfully different.
Unless you have rely big code bases I usually have a single workplace for all of my dev work. That way I just open any solution that I want.
I use workspaces for other tasks, like admin or merging... Or bug fixing on specific versions.
I have Visual Studio 2012 and when I'm trying to get last version it doesn't work and it says that it's says that "All files are up to date". It is because I deleted file locally after I got it from TFS and I guess in Visual Studios memory it's written that there were no changes from that time I got it and now it doesn't let me download it although I don't have it.
How to "tell" VS that my local folder is changed?
P.S. I guess it can be also done with "Get specific version" but that option doesn't appear to me when i right-click on file I want to get from server.
EDIT:
I found that my workspace changed automatically (or rather with me not being concentrated while making new project), so VS was actually checking other directory all the time. For all those who might have the same problem - check your local path and if you see that it's not good, change it.
Here is how you can change it:
http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/d0c6982f-4f5e-4b1c-830b-3af9fb127922/
You are right, TFS saves what version he gaves you and changing/deleting it without to notify TFS, you won't get anything. The "Get Specific Version ..." is what you need. Therefore rightclick on the item you want, in context menu choose "Advanced --> Get Specific Version". Check the second option to "Overwrite all files even if the local version matches the specified version".
Not saying this is a solution, but I had similar issues after remapping one of my projects. Ultimately what I did was delete my local Solution File (.sln) and re-opened the project via the Project File (.vbproj). After that I was able to see all of my latest file versions that appeared to not be down loading. Once you click save on anything it will re-prompt you to save a new solution file.
i don't know if this is specifically what the OP was trying to accomplish, but here's my story: my machine crashed, had to get it reimaged; once VS2015 was installed, i went to source control explorer, right clicked the branch i needed >> Advanced >> Get Specific Version, checked the "Overwrite..." boxes, clicked "Get" and got the "All files up to date..." message. buster. obviously the code was NOT up to date.
fast forward: i fixed this issue by deleting my workspace's pertinent mapping to code base i needed, saved it, and re-added it.
hope this saves some headaches.
You'll want to Get Specific Version and to check the box to enable overwriting of existing files. That will ensure you're actually up to date.
You can also switch from a server worspace to the new local workspace which should also help solve issues like this.