I'm on VS Community 2017.
I'm trying to permanently ignore the packages folder from being checked-in.
I went to Source Control Explorer, but the Cloak option in the file/folder's context menu, under Advanced is grayed out:
I tried adding a .tfignore file in the root folder adding packages and /packages to it, but it didn't do the job.
Any ideas?
Cloaking is the process of defining which folders or files should be
** ignored by the workspace on your development machine.**
Which may not be suitable for your situation. You could only cloak files/folders already in source control. If your packages folder is newly add in pending changes and not checked in, the cloak option should be grayed out.
Give a try with declaring below instead of only ignore \packages in your .tfignore file and add a disableSourceControlIntegration in a NuGet.config file, try again.
\packages
!\packages\repositories.config
For more detailed steps please refer to this question: Get TFS to ignore my packages folder
Another way is only check the packages folder to TFS (without any files or sub-folders) and then do the cloaked operation.
More info about the nuget package restore/TFS please refer this tutorial-- Package Restore with Team Foundation Build
You can only cloak things that are committed to the server already and since you have a pending add on the packages folder, it is not.
The package folder is added byt the Package Manager, but you can configure it to skip that step by creating a NuGet.config file in the solution directory setting disableSourceControlIntegration to true.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
Related
I have read and gone trough the following:
https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore#enabling-and-disabling-package-restore
https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore-troubleshooting
Why is there no packages folder in .my NET Core solution's containing folder?
'nuget' is not recognized but other nuget commands working
https://www.skylinetechnologies.com/Blog/Skyline-Blog/July_2016/Relocate_NuGet_Package_Restore_Folder
But i still have issues with the Folder Packages which contains the Packages for my solution, when i check in my code, for my on my side everything works fine, when someone else gets the checked in solution, he has to change the path that is set in the ProjectNameFile.csproj because the path there contains
../../../../NuGetPackages/....
but should be (and only works if changed to)
../Packages
But than when this persons checks in and i get this version, my packages folder is gone ... We have been using TFS on other projects here but this is a first for me ...
I tried all what the links i posted are suggestion but with no luck.
Tools > options > NuGet Package Manager looks like this:
I have a NuGet.Config file on the same level as my projectname.sln file which has following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<!-- I tried each line below seperately and together -->
<add key="globalPackagesFolder" value=".\packages" />
<add key="repositoryPath" value="C:\Development\projectname\Packages" />
</config>
</configuration>
So what i did now is i created a Packages folder on the projectname.sln level and when i build my solution, this works but hey, i can't do that each (X) time and i am sure there is a way of achieving this but don't know how.
Thank you in advance for any feedback.
How to properly configure NuGet Packages for collaboration with DevOps (TFS)
I suppose you are using the packages.config as nuget package management, because you said " he has to change the path that is set in the ProjectNameFile.csproj because the path there contains ../../../../NuGetPackages/....".
So, if you are using packages.config, you should use relative paths for the repositoryPath in your nuget.config file when you build the project with Azure DevOps.
As we know, when we build the project in the Azure DevOps, Azure DevOps always copy the project to the path like D:\a\1\s\xx, which is different with the path in your local. And NuGet always use the relative paths (..\packages or ../../../../NuGetPackages/...)in the ProjectNameFile.csproj like:
<Reference Include="packagename, Version=3.0.0.0, xxx">
<Private>True</Private>
<HintPath>..\packages\xxx\lib\net45\xxx.dll</HintPath>
</Reference>
In this case, when we build the project, nuget will still restore the nuget packages to absolute path C:\Development\projectname\Packages, but since the location of the project has changed to the D:\a\1\s\xx, so the relative paths for the HintPath in the .csproj file should also be changed accordingly, otherwise nuget can't find the corresponding dll file.
So, we should set the repositoryPath as relative paths in the nuget.config file, like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value=".\packages" />
</config>
</configuration>
With this setting, the path of the packages folder are based on the file nuget.config. As long as you have not modified the location of the nuget.config file, the HintPath does not need to be modified.
Note:
globalPackagesFolder is uesed for another nuget management type packagereference.
If you are working with someone else to develop a project, you need to unify the location of the nuget package, rather than continually modifying the HintPath manually. Otherwise it will cause confusion in your development.
Hope this helps.
I have seen few web posts and solutions but do not seem to work.
Am i missing the obvious?
this is what I have
At Solution level and not where the package resides
I have a folder like the pic below
.tfignore contains the following
# Ignore NuGet Packages
*.nupkg
# Ignore the NuGet packages folder in the root of the repository. If needed, prefix 'packages'
# with additional folder names if it's not in the same folder as .tfignore.
packages
# Omit temporary files
project.lock.json
project.assets.json
*.nuget.props
nuget.config.xml contains
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
When I try to checkin items in visual studio 2017 it still shows all the packages.
Can somebody help with what I am doing wrong?
thanks
According to your screenshot, you are not using the correctly .tfignore file. This file does not have any suffix. One way to create it, suggest you to rename a new.txt file with "tfignore." It will auto change to right .tfignore file.
You can also use the auto automatically generated .tfignore file, follow below steps in my answer here.
More detail info about the .tfignore file please refer this tutorial.
Note: This .tfignore file will not affect with those files already in source control. You need to remove them from source control first. Also make sure your .tfignore files have checked in source control.
In my opinion .tfignore should be located in solution folder directly and the file name is .tfignore and not .tfignore.txt
The nuget config name is NuGet.config and not nuget.config.xml
If packages are installed before .tfignore created, then you have may be to "undo" package folder first in Source Control explorer.
Personally I would ignore the entire nuget packages folder with exception of targets
ASP.NET 4.5 MVC application
Builds/runs just fine locally
Packages folder NOT checked into source control
Source control looks like this:
MyProject
-.nuget
-.tfignore
-MyProject.Web
-MyProject.Utilities
-MyProject
-MyProject.sln
Inside of the .nuget folder, there is only one file: NuGet.config, which has this inside:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
I can delete the packages folder locally, run it, and it correctly downloads everything again.
When I kick off a build from Visual Studio which should build the solution and deploy it to Azure Cloud Service, the build fails saying:
The type or namespace name 'WindowsAzure' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)
The "new" way to do this is to run
nuget.exe restore "MySolution.sln"
I put my (versioned) nuget.exe files on my build server like this:
c:\MyProgFiles\NuGet\2.8.6\nuget.exe
c:\MyProgFiles\NuGet\3.3.0\nuget.exe
Then before I build, I call
"c:\MyProgFiles\NuGet\2.8.6\nuget.exe" restore "c:\MyFullPath\MySolution.sln"
You can also read this about "how to clean up old nuget stuff"
http://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore
(using CI macros when possible to create the file names)
I also put these lines before the "nuget restore" to help with debugging.
"c:\MyProgFiles\NuGet\2.8.6\nuget.exe" sources list
"c:\MyProgFiles\NuGet\2.8.6\nuget.exe" locals all -list
BTW: If you have a package source where the packages might get deleted, then add this to your build scripts (before the "restore" mentioned above)
"c:\MyProgFiles\NuGet\2.8.6\nuget.exe" locals all -clear
This will clear your local cache and force a fresh download.
Again, the value here is ONLY if you use a source where packages get deleted.
I cannot make it, so that the Publish from visual studio doesnt delete the App_Data folder on the server website. But i would also like it to keep deleting all files (except that folder) to keep the dir "clean".
I have tried this in csproj, .pubxml. And alterations of it (theres one not OnBeforePackageUsingManifest, but iis something)
<PropertyGroup>
<OnBeforePackageUsingManifest>AddCustomSkipRules</OnBeforePackageUsingManifest>
</PropertyGroup>
<Target Name="AddCustomSkipRules">
<ItemGroup>
<MsDeploySkipRules Include="SkipDeleteAppData">
<SkipAction>Delete</SkipAction>
<ObjectName>filePath</ObjectName>
<AbsolutePath>$(_Escaped_PackageTempDir)\\App_Data\\.*</AbsolutePath>
<XPath>
</XPath>
</MsDeploySkipRules>
<MsDeploySkipRules Include="SkipDeleteAppData">
<SkipAction>Delete</SkipAction>
<ObjectName>dirPath</ObjectName>
<AbsolutePath>$(_Escaped_PackageTempDir)\\App_Data\\.*</AbsolutePath>
<XPath>
</XPath>
</MsDeploySkipRules>
</ItemGroup>
</Target>
I even get if i use "SkipAction=Delete" thats it is unable to do so, as Delete is not recognized.
Are there any way to do this? preferably from .pubxml, but csproj will do aswell. Not that much for having to deal with msdeploy command line.
Using visual studio 2015.
Came here looking for a way to keep the "certify the web" .wellknown\acme-challenge folders web.config during a Visual Studio 2019 publish. Thought I'd share it.
Adding the following to pubxml file will cause deploy NOT to delete the web.config during publish.
<ItemGroup>
<MsDeploySkipRules Include="CustomSkipFile">
<ObjectName>filePath</ObjectName>
<AbsolutePath>.well-known\\acme-challenge\\web.config</AbsolutePath>
</MsDeploySkipRules>
</ItemGroup>
Hope this helps somebody!
This (quite recent) SO answer mentions that MsDeploySkipRules settings are effective only when publishing through command line.
When Web Deploy-ing from VS IDE, it suggests checking the following options:
Remove additional files at destination
Exclude files from the App_Data folder
If "Remove additional files at destination" and "Exclude files from the App_Data folder" are both selected, EVERYTHING will be still deleted first and App_Data folder will be ignored (It wont be published).
The only recommendation I can give is to make the folder hidden, this way even "Remove..." is checked it wont be deleted.
I'm using NuGet Package Restore. I want to specify custom sources during a TFS build server process.
The NuGet.targets file in the hidden '.nuget' folder says that you can either specify sources repositories, or that it will fall back to the NuGet.config in %APPDATA%\NuGet\NuGet.config.
There is however a NuGet.config in the hidden '.nuget' folder as well. I assumed that if you did not specify sources repositories in NuGet.targets that it would fall back to the NuGet.config in the hidden '.nuget' folder. This doesn't seem to be the case.
Any ideas?
With the current version of NuGet it's possible to specify custom repositories in the solution's NuGet.config file and enable package restore during a build.
Having this NuGet.config file allowed us to automatically restore packages from internal repository under a TFS build without any other actions in the build definition:
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageSources>
<add key="Internal" value="http://MyInternalRepository/nuget" />
</packageSources>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>
</configuration>
Note: TFS2013's default Build Process Templates already implements NuGet Package Restore workflow without any special configuration as stated here: http://docs.nuget.org/docs/reference/package-restore-with-team-build
If you enable package restore, you'll find a NuGet.targets MSBuild file in the $(SolutionDir)\.nuget folder.
You can set the package sources by modifying the <PackageSources>""</PackageSources> element.
Example:
<!-- Package sources used to restore packages. By default will used the registered sources under %APPDATA%\NuGet\NuGet.Config -->
<PackageSources>"http://packages.nuget.org/api/v2/;http://myget.org/F/myfeed/"</PackageSources>
According to pranavkm, one of the NuGet devs, at the time of this writing NuGet Package Restore will not use the NuGet.config in the hidden '.nuget' folder for sources. It's only used at the moment for a solution specific setting (to ignore source control bindings). He says it is on the radar for the NuGet team to leverage all aspects of NuGet.config but that it keeps getting bumped in priority.
Another option is to add sources to a machine-wide (not user-specific) nuget config on the build server.
https://stackoverflow.com/a/27569020/374837
in tfs build 2017 when you use the NuGet Restore task version 1.* you can select the NuGet.Config file to use during the build.
See image below NuGet Restore Task