R Change Package Location

[Bridget Peral]

Tochange the nuget packager folder, you can you can set "NUGET_PACKAGES" environment variable. Just Set "NUGET_PACKAGES" = "c:\teampackages". Or you can place a NuGet.Config file next to the solution with the following content:

I noticed that you are creating Xamarin.Forms project with Visual Studio Community 2017, the reference should be PackageReference, for this sort of project, you should use add below code to the .csproj file:

You'll notice that I do not keep external libraries inside the source folder. I'm also very interested in using NuGet but don't want these external libraries inside the source folder. Does NuGet have a setting to change the directory that all packages are loaded into?

As Azat commented, there is now official documentation on how to control the package locations. The release notes for 2.1 specifies the following configuration in a nuget.config file (see the release notes for a description of valid places to put the config files and how the hierarchical configuration model works):

This would change the packages folder for the configuration level you put the file in (solution if you put it in the solution directory, project in project directory and so on). Note that the release notes state:

The nuget.config file in the .nuget folder is relative to that folder. This is important because if your new folder is something like '../Packages' that will put it where it always goes out of the box. As @bruce14 states you must do '../../Packages' instead

I could not get the latest nuget (2.8.5) to find a packages folder outside of the standard location without enabling package restore. So once you enable package restore then the following should be added to the nuget.config file inside of the .nuget folder to change the location:

(This is important) If you make ANY changes to the package folder location inside of the nuget.config files you must restart visual studio or close/reload the solution for the changes to take effect

The location in which to install NuGet packages instead of the default $(Solutiondir)/packages folder. A relative path can be used in project-specific nuget.config files. This setting is overridden by the NUGET_PACKAGES environment variable, which takes precedence.

So now, if you add 'repositoryPath' config somewhere in NuGet.config (see the release notes for a description of valid places to put the config files), it will restore all packages into single location, but... Your .csproj still contains hints to assemblies written as relative paths...

I still don't understand why they went hard way instead of changing PackageManager so it would add hint paths relative to PackagesDir. That's the way I do manually to have different package locations locally (on my desktop) and on build agent.

Based on my experience the lib folder was created on the same level where Nuget.config was found, no matter where sln file was.I tested and the behavior is same for command line dotnet restore, and Visual Studio 2017 rebuild

One more little tidbit that I just discovered. (This may be so basic that some haven't mentioned it, but it was important for my solution.) The "packages" folder ends up in the same folder as your .sln file.

Looks people in Nuget team finally started to use Nuget themselves which helped them to find and fix several important things. So now (if I'm not mistaken, as still didn't migrated to VS 2017) the below is not necessary any more. You should be able to set the "repositoryPath" to a local folder and it will work. Even you can leave it at all as by default restore location moved out of solution folders to machine level. Again - I still didn't test it by myself

According to the NuGet Documentation, the value can be overridden by a nuget.config file placed in the current folder (e.g. solution folder) or any folder up to the drive root. Note that NuGet 3.3 and earlier was expecting the nuget.config files to be placed in a .nuget subfolder. This got me at first, as my setup was originally targeting older versions, so I deleted this subfolder.

Create a nuget.config file in the same directory where your solution file is located with the following content, and restart the visual studio. (I test it with VS2022) [./packages - Replace it with your package path]

Too localized - this could be because your code has a typo, basic error, or is not relevant to most of our audience. Consider revising your question so that it appeals to a broader audience. As it stands, the question is unlikely to help other users (regarding typo questions, see this meta question for background).

My SSIS Package are located in shared drive with a long path name. To make the packages easier and not to remember long path name, I use "Map my network drive" option and use X: drive as an alias to access packages. Next thing I know that all my packages locations have been updated as "X:\Package5.dtsx". Now if the pseudo network drive is disconnect, I cannot access the packages (outside the server).

How can I change the package name from X:\ to actual share drive name (where my package are stored)? I don't want to do some changes that could effect how this package run since they are very critical to the business continuity

If one of your jobs work like that (assuming most all are setup the same and this way, etc), you can probably script out the SQL Agent jobs through SSMS by pressing F7 (once SQL Agent jobs is highlighted), selecting them all from the right pane window, right click, then create to new query window, then do a mass CTRL+H and do a find and replace to replace X:\ with \\\, and then run that.

This is a software question, specific to MiKTeX: I have automatic downloading of packages enabled, so that if I try to use a style that's not in the existing directory trees, it is downloaded from CTAN and installed. The problem is that MiKTeX installs it under %APPDATA% (at C:\Documents and Settings\\Application Data\MiKTeX\2.9), which bloats my roaming profile. Is there a way to change this destination?

I already have another root for styles I install myself, but I can't get MiKTeX to use it for auto-installed packages. In the Roots list in MiKTeX Settings (mo.exe), the %APPDATA% folder has the tag "UserInstall". It won't let me edit or delete its path, or tag another root "UserInstall". Is there a way to do this, or am I stuck with rearranging the downloaded packages by hand afterwards?

As Ulrike explained in the comments above, it seems that MikTeX allows the UserInstall directory to be configured only during installation. So, it's easiest to just re-install it, calling the installer from the commandline with suitable options. The full set of commandline options for the installer is documented here.

I first removed the existing MikTeX by running the uninstaller from the Start menu. I then opened a command prompt (this is on Windows), switched to the directory containing the downloaded installer, and ran the following:

I used --shared since it's being installed for all users, but I was asked again during the set-up dialog anyway. There are also options --user-config and --user-data (I don't mind leaving those in the default location).

I am just setting up a new computer, so this was a no-brainer. I follow best practices and keep all style files that are not managed by MikTeX in a separate texmf hierarchy, so there was no need to salvage anything before uninstalling. But if you have been dropping your non-CTAN styles into the MikTeX texmf tree (definitely not a good idea), or have a huge texmf tree and a slow internet connection, or use your computer off-line a lot and don't want to be surprised by missing packages, you can follow this procedure, which lets you use your old texmf tree as the data source for the new installation (thanks @Speravir for the pointer).

As opposed to what the accepted answer says, it not "easier" to reinstall. One can make a simple edit in the registry: the install dir for packages is set on HKEY_LOCAL_MACHINE\SOFTWARE\MiKTeX.org\MiKTeX\2.9\Core\UserInstall

Have you considered the idea of relocating /var/lib/pacman to /usr just like openSUSE and Fedora already did (years ago) due to possible rootfs inconsistency caused by snapshot/rollback capabilities of modern Linux filesystems like btrfs and bcachefs?

/var/lib/pacman is currently the only directory in /var that is treated as a core Arch Linux component and in my opinion deserves to reside in a system-specific path like i.e. /usr/lib/sysimage. I personally think that moving pacman's default DBPath out of /var is justified by a few very important use cases such as the maintenance of rootfs snapshots, read-only filesystems and for the sake of backup sanity in general. The relocation could dramatically simplify the backup/restore of the system state and will be a beneficial change for both device-mapper and btrfs-based filesystem layouts.

I want to move installed snap packages to home directory. Snap packages are slightly larger than .deb packages thus they take space in my root partition. I know packages are located in /var/lib/snapd/snaps and they are working with mounting the package to /snap/app_dir. I tried to simlinked, But it didn't work.

The first solution that was strongly refused by the community, but I didn't try, is to use symbolic links to link the directories that lead to snaps. This method seems not to work as the community replies says that AppArmor does not work with symbolic links.

The Second solution is mount --bind the directory /val/lib/snapd/snaps which works fine for me with the already installed applications but failed to install new applications because I was moving the directory to another partition. That gave me an error about hard linking the snap application with the cache directory which is located in /var/lib/snapd/cache. I don't know if this solution may work if the location are in the same partition or not; but this is the reason why I am moving the snap directory to free some space from partition to another one.

3a8082e126