I noticed that for VS Projects controlled with TFVC, debug folders are ignored naturally without having to create a .tfignore file to exclude them. However, I have a legacy project that seems not to follow this behavior and I am unable to fix it because I don't know who's responsible for that behavior in the first place.
Can you explain why debug folders are ignored naturally without having to use a .tfignore?
There are already pre-defined list what files will be excluded by TFS if there is no custom .tfignore specified/present on the system.
You could refer to the "LocalItemExclusions.config" file under the path "C:\Users\youraccount\AppData\Local\Microsoft\Team Foundation\x.0\Configuration\VersionControl" folder and open".
(There may several folders named like 1.0, 2.0, 3.0, you need to make sure open the folder that match your TFS version.)
You could see that these folder and files types are ignored by default and they are defined in that file.
<Exclusion>bin</Exclusion>
<Exclusion>obj</Exclusion>
<Exclusion>*.exe</Exclusion>
If those files still could not be excluded by default in the legacy project on TFS, as a workaround, you could manually add a .tfignore file in that specific project.
SOLVED The problem turned out to be that - for any reason - the one who added the project to TFS the first time, added the debug and release folders with it - either deliberately or his VS was miss configured - and hence, the VS will keep track of those files even if ignored by default (natural behavior).
In order to solve it, I had to delete those folders form the TFS itself and then get the latest version to get the local copies deleted as well ... later after building the project and having those folders created again, VS will not recognize them as new files/folders because they are ignored by default as mentioned.
Related
Not sure if this is the correct place to ask this but there have been a lot of visual studio questions in the past here.
I am currently creating a lot of npm packages in a solution and as part of the package, I have to create a package.json file.
Once I save the file, it creates a node_modules folder and downloads all the dependent npm packages to it. Now I have got azure dev ops to ignore these files so they aren't checked in by adding the node modules folder to the list of ignored folder names, but I also want to exclude them from my project so that it doesn't lock my computer every time it tries to write all the file names in to the .proj file.
Is there a way to automatically tell the project or solution to auto exclude this folder - like a solution ignore file I can add the name to?
Or is there an option somewhere that folders that aren't created through vs, aren't automatically added to the project - this is how my earlier versions of vs worked - new folders not created through vs would have to be manually included if you wanted them in the project / solution
Ok this is due to the project type that I used when creating the project - I created it as a .net core project and that seems to add files by default and only exclude them if you tell it to, if I change this back to a .net standard project, it works as I would expect - only includes files you drag into the project or tell it to include
I'm working on C++\CLI that someone else started. The solution is made up of 3 C projects and 1 C++\CLI project that uses them.
I've duplicated the C++\CLI project and change it name and ProjectGUID property in the vcxproj file.
The problem is I still get the error listed bellow.
How can I fix this?
Warning 1 warning MSB8028: The intermediate directory (Debug\) contains files shared from another project (my_project.vcxproj). This can lead to incorrect clean and rebuild behavior. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppBuild.targets 388 5 seebo_prod_line_tool
Same problem here, solved by
Deleting all Debug\ and Release\ folders (there were more of them in subfolders where I didn't expect them)
Changing the .sln file manually to fix the name of a referenced C++ project (.vcxproj) which apparently was not renamed when renaming the project in Visual Studio
My suggestion is to make sure the intermediate directory for each project is different (as suggested by someone else earlier.)
To do this,
Open the project's Properties dialog
Under Configuration Properties, select General
Make sure the Intermediate Directory for this project is unique to this project.
I ran into this problem because using previous versions of Developer Studio I had a host of companion projects but wanted all of them to put their output in a common "Release" folder. Inadvertently I had set the same common release folder settings in the Intermediate Directory path for some of the projects (but not all).
I found you can disable these types of warnings by added the following to the project file:
<PropertyGroup>
<IntDirSharingDetected>
None
</IntDirSharingDetected>
</PropertyGroup>
I myself also encountered this kind of warning.. But I obtained this in a different situation, I renamed my whole solution/project via IDE and thus making another copy of an entirely different project. So what I have here is a total of two projects sharing one common resource, source and header files. This makes this warning pop up.
I fixed this by deleting the files associated with the project, which you renamed previously. Delete these INSIDE the DEBUG folder. In your case, try deleting all 'my_project' files, regardless of any file extensions because it shares resource files to your duplicated project.
The cause of this problem is copying an intermediate directory that was created by Visual Studio, and that already contains files from a previous build. It is not a problem in the project settings, but a problem caused by the existence of unexpected files from another project. In this context the warning is benign, but annoying.
The minimal solution is to find and delete each such file. The simpler solution is usually to "super clean": delete every directory created by Visual Studio (with names like bin, obj, x64, x86, Debug, Release and so on), and allow VS to re-create them during the normal build process.
I have experienced this problem as well, and for me, the cause was that there were multiple libname.tlog directories inside the intermediate build folder. These directories contain libname.lastbuildstate files that I assume are used for dependency checking. Doing a Clean of the project I don't think will delete these extra directories.
So in this case I was able to delete the libname.tlog directories and build again. I don't know how it got into the state of having multiple directories inside each intermediate directory -- perhaps they were created when I updated the VS version.
I'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.
I have read this post thoroughly: How does Visual Studio's source control integration work with Perforce? and found it very informative. However, I have a specific issue that is blocking my use of Perforce in VS.
For the most part, I have no complaints about the plug-in (I'm still using the P4VSCC plug-in because the new plug-in requires conversion by the entire team which can't happen at this time). Once I understood the idiosyncracies, I've had only one problem working with the plug-in.
Our solutions contains many projects that are built into a single deployment package. As such, each assembly is versioned the same. To accomodate this, and other common aspects, we have defined a common "SharedVersionInfo.cs" file which contains the AssemblyVersion and AssemblyFileVersion attributes typically found in the AssemblyInfo.cs file. This file is stored in an Assets folder beneath the solution folder and added to each project's Properties folder as a linked file. This works great from a version management perspective as we only have to change the version in one place and all assemblies are updated. However, Perforce has a problem with this when a new developer first opens the solution or when a new project is added. The only remedy we have currently is to remove all of the linked files (there are 3 per project in this solution), bind the project to source control, then re-add the linked files.
This isn't such a big deal when we add a new project but the solution contains 80 projects (and counting), so this isn't a viable remedy for a new developer!
My understanding is that the problem has to do with where VS thinks the binding root for each project is. After some research, I was led to find where the MSSCCPRJ.SCC files are for the projects. I found there are numerous SCC files scattered throughout the solution structure. So...
First question: Why are there multiple MSSCCPRJ.SCC files in my solution structure?
We also have several shared/common projects that we use in our solutions. This leads to the following folder structure:
/Source
/CommonTools
/ProjectA
ProjectA.csproj
/ProjectB
ProjectB.csproj
/MySolution
/Assets
SharedVersionInfo.cs
/Project1
Project1.csproj
/Project2
Project2.csproj
:
/ProjectZ
ProjectZ.csproj
MySolution.sln
Where both ProjectA and ProjectB are part of MySolution.sln
Second Question: How can I setup the bindings so the /Source folder is considered the root? This would ensure that all projects included in the solution are under the same binding root. Perforce considers this folder to be the root, how do I get VS and the plug-in to do the same?
Since no one else has offered up a solution, I thought I'd follow-up with my own findings for anyone else that comes across the thread.
First, I still have no idea why Visual Studio creates multiple MSSCCPRJ.SCC files but these are the key to establishing the "binding root" for a solution. It is critical that this file exist at the highest level necessary so that ALL of the projects in the solution are in sub-folders relative to the location of this file. In my example above, the MSSCCPRJ.SCC needed to be located in the /Source folder. Having it in the /MySolution folder caused the original problem when adding projects from /CommonTools into the solution.
That said, resolving the issue was no easy task. I had to manually edit the .sln and all of the .csproj files in Notepad. What I found was that some of the .csproj files had the following elements identifying the source control settings:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
I don't know what SAK stands for, but my understanding is this tells Visual Studio to use the binding information contained in the .sln file.
I had to change these to:
<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccAuxPath />
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
where the SccLocalPath value is the relative path from the .csproj file to the MSSCCPRJ.SCC file.
I also had to change the SccLocalPathX and SccProjectFilePathRelativizedFromConnectionX statements for each project in the .sln file. The SccLocalPathX value should be the relative path from the .sln file to the MSSCCPRJ.SCC file - a dot (.) if in the same folder. SccProjectFilePathRelativizedFromConnectionX should be the relative path from the binding root to the .csproj file.
I wish I could say that having that in place, I never had to repeat these steps. Unfortunately, I still have to go in and make corrections every time I added a new project to the solution. Visual Studio still wants to use SAK for the elements in the .csproj file and sometimes the values in the .sln file aren't quite right.
But, at least I know what to look for and what needs to be done to achieve my goals. If anyone else has a better solution or a way to configure VS and/or Perforce so these settings are created correctly up-front, I'll gladly give credit.
Hope that helps...
I have a Web Setup project in VS. I'll be switching to WiX, but that's in the future and currently I need to solve the following issue.
I need to exclude some common dlls from the project. So I build the project, VS updates the list of Detected Dependencies. I exclude them and the setup builds. I check the file list with Orca and the files are not included in the installer.
But when I clean my output directory, reload the solution and do the build, some of the dependencies do not show as excluded! And so they end up in the MSI. (This is what is happening on the build machine).
I think that the problem might be with the fact that these are second-level dependencies:
my app -> NHibernate.dll -> Antlr3.Runtime.dll
(Antlr dll ends up in the MSI).
Is this a bug or am I missing something?
I found this page on msdn that has a work-around for the Exclude flag being reset to False:
Previously excluded files are included again when the solution is re-opened
When you exclude a file from a Setup project, you may see that the file is included again after you close and re-open the solution. This may occur if there are two copies of the same DLL file from two different source locations.
To work around this error, change the Copy Local property on one of the files:
In Solution Explorer, click on the DLL reference that you want to remove.
On the View menu, click Properties Window.
Change the Copy Local property to False.