I want to install PyCharm, PhpStorm, etc. into some folder on drive D.
Though JetBrains Toolbox not having the option to do so in my view.
So the question is that is it possible to customize the installation folder for JetBrains IDEs when installing via Toolbox?
Yes, you can configure the install location for apps in the Toolbox settings. However, this will install ALL apps under the specified directory (and move existing ones there). If you want to define a specific install location for each IDE, then that is not possible... yet.
Also see this support question. The second answer explains how you can manually update the install_location property in .settings.json. This will change the install location for future installations, and your existing apps will not be moved.
[Windows 10] I found a manual location changing option that is not well explained on any forum.
After you install Jetbrains Toolbox, if you cannot change the Tool install location from the app UI, and it goes into "Failing to change location, because application is in use, or something like that" if you are trying to change from there, close the Toolbox application(kill it from Task manager, or close it from the toolbar), and after you go to the default installation location of the Toolbox app(more info about this, here: https://toolbox-support.jetbrains.com/hc/en-us/articles/115000978804-Where-are-the-IDEs-located-on-my-hard-drive-) and open .settings.json file
In the .settings.json file you need to add/update the following code line:
"install_location": "<default_location>",
There, add your desired install location instead of <default_location> if there exists the line in the file. If this line does not exist, add it the begining of the file. Don't forget to add the " , " in the end of the line.
Please help to spread this message to our fellow friends who are using Jetbrains Toolbox and are having this problem.
The location of the setting in the UI seems to change with subsequent Toolbox versions.
Currently it's under Toolbox > cogwheel icon > Toolbox App Setting > Tools > Tools install location.
Toolbox operates under current user permissions, not as administrator and it cannot ask for privileged access yet. In partical term it means if you wan't to install it under "C:\Program Files" you will have create "JetBrains", or whatever root directory you want, manually there, in your preferred file manager, then apply permission settings allowing you current user to write to that directory.
Looks like they invested some time in this. No need to play around with config files anymore:
Open your toolbox application
Open settings.
Open tab "Tools"
Change "tools install location"
Hit "apply changes"
Wait until files are moved
Related
I launch RStudio in a Docker container and access to it via the browser in the host OS. I prefer the settings Console on Right and Emacs Key Bindings, so usually check these options by hand in GUI. The container does not share the home directory where .rstudio/ directory stands, every time I destroy the container, those settings are lost.
I suspect there's a options or global configuration files that make my preferable settings default.
How can I configure the default settings of RStudio ?
There's no supported way to do this in RStudio 1.2, but RStudio 1.3 (which will be available soon) makes it possible. You can try a daily build of RStudio 1.3 here:
https://dailies.rstudio.com/
Specifically, you will want to put your settings in /etc/rstudio/rstudio-prefs.json, as described here:
https://docs.rstudio.com/ide/server-pro/latest/r-sessions.html#customizing-session-settings
To figure out what exactly to put in that file to get the layout and keybindings you want, I recommend setting up RStudio the way you want it by hand, then copying the config out of the ~/.config/rstudio/rstudio-prefs.json file.
There is also documentation on everything you can set in the admin guide:
https://docs.rstudio.com/ide/server-pro/latest/session-user-settings.html
(The admin guide is for the professional version, but all of the above also applies to the open source edition.)
I'm creating a Iexpress package, and no matter what on the final step it pops up the message "Unable to open report file" and stops. I am searching Iexpress.exe and right clicking, then choosing "Run As Administrator" to start it. The problem persists.
I had this error running as my account (domain admin) not specifically telling it to run as administrator, removed spaces then re-ran working fine under Windows 10 1809 you shouldn't need to change to a different application to create .EXE files using IEXPRESS this is working fine under Window 10.
The way to fix this problem:
Go to the folder where your files you want to be in the package are
Go to the top bar (Where it says where you are on your drive), and type iexpress
Do the creation as normal, but the names you give the installer shouldn't have any spaces.
I did it this way without admin permissions.
I ended up moving on to Inno Setup Compiler. Turns out Iexpress isn't supported anymore. I recommend Inno to anyone making their own programs.
This happens when SourceFilesX or TargetName paths in the directive (i.e. the files you've added from the wizard) contain spaces. And while the issue with the TargetName can be fixed with adding double quotes the only workaround I've found about the source files is to put them in a folder path that not contains spaces.
I'm having a weird problem...
I created a basic WinForms app in C# using Visual Studio 2013, and I added a Setup & Deployment project to the solution to build my .msi installer. For the Setup & Deployment Project's properties, I have the DetectNewerInstalledVersion to true, and the RemovePreviousVersions set to true. Then, with every build, I'll increment the version number and let Visual Studio change the ProductCode. Lastly, I'll make sure that the UpgradeCode stays the same.
In this configuration, if users run the .msi with a previous version installed, then it performs an upgrade. Everything works (as in all files are updated to the new versions, etc.). But, when they open Add/Remove Programs, the icon for the old version(s) is still there, as well as the icon for the new version.
For example, if they used the .msi to install MyApp version 1.1, then used the .msi to upgrade to 1.2, then again to 1.3, then MyApp will correctly update to version 1.3, but the user goes to uninstall it in Control Panel->Programs and Features->Uninstall a program, there will be three MyApp icons (one for each version). And to properly uninstall MyApp, they must right-click/uninstall all three. If I delete the old versions from the registry (the usual fix for stale icons), then MyApp will not uninstall correctly. The uninstall will go through the motions without error, but the program files and icons will remain, and the application will still function like normal. To troubleshoot, I've made a series of builds with sequential version numbers, then opened each build's .vdproj file in a text editor to ensure that the ProductCode and PackageCode have been updated, but the UpgradeCode remains the same. They do, so it's not a problem of the UpgradeCode changing. I've also tried deleting the registry keys for the old icons. This gets them out of the Programs and Features uninstall list, but it prevents the program from being properly uninstalled this way, so this isn't an option.
Anybody have any ideas?
This will happen when the first install is (say) Everyone and the upgrade is installed Just me (or vice versa). One type will not upgrade the other, so files will be replaced if installed to the same location, but there will be an entry for each in Programs&Features. They all must be Everyone or Just me to replace previous products.
You can install the upgrade with msiexec /I [path to msi file] /l*v [path to a log file] to see what's going on. If you search for occurrences of FindRelatedProducts you should see something about what it found and if it was the right context.
Note that Visual Studio setups can change the context if you do not have administrator privileges. You might specify an Everyone install but Visual Studio will change that to Just me if you don't have the privileges.
Ok. Weird...
The issue comes from the way that it's run. Once installed, the program checks the network share for a newer .msi, and if it detects one, it downloads it, then launches it with Process.Start and command-line args. The StartInfo.Arguments string looked like:
startInfo.Arguments = "/i \"[MSIPATH]\" /log \"[LOGPATH]\" TARGETDIR=\"[APPPATH]\" /qr+";
I guess someone fat-fingered the UI mode switch at the end. The "/qr+" switch should be "/qb!-". When I changed it, the problem stopped. I don't think that "/qr+" is even a valid switch, so I'm not sure why the install didn't just fail outright??? Anyway, that was the problem should anyone see something similar.
Special thanks to PhilDW for pointing me to the logs. :-)
I am new to nopcommerce and I am developing a plug-in in it.
I have partially created my plug-in and meanwhile i have found that if i change anything in plug-in's code (View, model, controller, services, etc.) then i have to UNINSTALL my plug-in and then INSTALL to see the changes.
It is really tedious task to do.
Is there any other alternative way to see changes especially for designing view where we just need to set our designing.
If it is possible to see changes by just reloading it in browser then it will be great for all.
Please reply if anyone has any idea about that.
All answers are accepted.
Thanks in advance.
As far as I know all installed plugins are cached into memory so just overwrite .dll in Plugins folder and you can either
Restart your application with IIS/WebMatrix
Go to Admin > Configuration > Plugins and in top-right corner of the plugins view hit "Reload list of plugins"
"Restart application" or maybe even "Clear cache" in top-right corner of the admin page may work too. Try it out.
You should clean the solution and then build plugins after making changes to the code of the your plugin.
I have a batch-file that I run each time I want to deploy changes to my plugin on my local IIS. It may be overkill, but it works. I keep it on my desktop. When I want to test changes, I right-click and "Run as Administrator".
#ECHO OFF
ECHO Stopping IIS
iisreset /stop
ECHO Clearing Temporary ASP.Net Files (Server cache)
for /d %%i in ("%systemroot%\Microsoft.Net\Framework\*") do for /d %%j in ("%%i\Temporary ASP.Net Files\*") do RD /q/s "%%j"
for /d %%i in ("%systemroot%\Microsoft.Net\Framework64\*") do for /d %%j in ("%%i\Temporary ASP.Net Files\*") do RD /q/s "%%j"
ECHO Building MyPlugin
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" /build Debug "C:\Path_to_Nop_Source\Plugins\MyPlugin\MyPlugin.csproj"
ECHO Deploying MyPlugin
xcopy "C:\Path_to_Nop_Source\Presentation\Nop.Web\Plugins\MyPlugin" "C:\Path_To_WebRoot\Plugins\MyPlugin" /D /Y
ECHO Restarting IIS
iisreset /start
ECHO Done
pause
When I ran into this problem I tried restarting everything starting with the app, then the app pool and even iis. Unfortunately it didn't work. What did work however was rebuilding the site again and copying it over again (mainly all the nop.core.dll, nop.web.dll etc.). I did copy the core dlls of the site the first time around too, but I guess the plugin was copied after those. I think the important part is that the core dlls need to be recompiled so they appear different to iis and cause the already loaded plugins to get unloaded from memory.
I'm quite sure that restarting the whole server would work too, but who would want to do that?
P.S. I was about to ask the same question, because I couldn't find this one while googling (probably because the title is a little too specific). I intended to name mine Plugin not updating after copying a newer version. What lead me to this question was the similar question block that appears when you write a question.
Update: So I discovered that sometimes rebuilding and replacing nop core libraries isn't enough. However in that situation using the "Reload list of plugins" option in admin panel did the trick. Another time I was trying to just use that option and it didn't work until I replaced the core libraries. So to reload a plugin one or both of those steps might be required.
I'm on Mac OS X, and I just installed a secondary drive, onto which I placed my user's home directory.
Now, when I launch Aptana/Titanium Studio, it says that specified workspace cannot be created because directory is either invalid or read-only.
What I guess that it's looking after the old file path.
In what file can I change to the new workspace location?
Thanks!
Found a workaround.
I simply added a symbolic link into my users’ folder:
myusername -> /Volumes/Second/Home/
Voilà!
I had the same issue. I tried to change workspace to a read only location and then couldn't restart.
I searched the usual suspects for a pref file but can't find it. I suspect it's stored somewhere deep in the Eclipse framework files.
I solved it by executing
./AptanaStudio3 -data ~Home
from
~/Applications/Aptana Studio 3/AptanaStudio3.app/Contents/MacOS/
to reset Workspace to ~Home
Hope this helps a future seeker
Is Aptana/Titanium Studio closing after the workspace message or you can get to the preference menu? If so you can change the workspace location by going to
Aptana/Titanium Studio > Preferences > General > Startup and Shutdown > Workspaces
Then when you next start the application you will be asked for you workspace location and you can browse to the new location.
You should be able to change it using the config.ini file located at /Application/Titanium Studio/configuration/config.ini.
I have not had reason to do this for Titanium, but I have done in the past for Eclipse and as Titanium/Aptana are basically Eclipse spin offs this should work for them as well.
Just in case anyone faced the same problem and the answer didn't work. My problem was trivial. There was no free space on my HD! (only 2MB). If so, free some space and re-launch Aptana.
(I am wondering why the message was that vague. Why not to say "Free some space" and "free" me from wasting my time!)
I know this is old but I ended up here after copying my Aptana Studio 3 data to a new computer, and placing my Workspace in a different location, which gives the same error that the Workspace can't be opened.
If you installed into the default location (on Windows) and want to tell Aptana where you've moved your Workspace, the file where you can set the path is:
%HOMEPATH%\AppData\Roaming\Appcelerator\Aptana Studio\configuration\.settings\org.eclipse.ui.ide.prefs