Tooling: Things in ".tfignore" still are shown in the Solution Explorer (and in pending changes)

[tommck]

Using TFS as our Source Control, we have a few folders in our ".tfignore", yet the folders are not ignored by visual studio and always show up in the Solution Explorer and also in the "Pending Changes" view.

So, it's not doing what I think it should be doing.

[sayedihashimi]

Tom, is this specific to ASP.NET 5 projects?

[tommck]

I don't know. That's all we have in the solution.

[tommck]

This is what's in our .tfignore file

# Ignore all of the HTML, CSS, JS build assets
\coverage
\dist
\.tmp
\node_modules
\docs

We use gulp to do some building. the "coverage", "docs" and "dist" folders are created during "gulp build". The "node_modules" folder is always ignored, so is the ".tmp". The others always seem to get added to my pending changes and solution explorer view

[sayedihashimi]

Tom, could you try with a non asp.net 5 project? It would take me some time to setup an env to test this.

[tommck]

Hmm.. I might be able to (I don't have rights to create new projects in our TFS server to test with).

[Eilon]

I would think that .tfignore files would still show up in solution explorer (why would they necessarily be hidden)? But showing up in pending changes definitely sounds wrong...

[tommck]

well, I guess I'm also thinking of a "Web Application" in the past, as opposed to a "web site". Web Applications did not automatically add files to them, Web Sites showed everything in the folder. I would think, with the ".kproj" file (soon to be ".xproj"), this would be more like an "application" than a "site", thus my expectation of not seeing the newly created files.

[davidfowl]

That's the wrong assumption. kproj tries to be the best of both worlds. There's no explicit list of files in the project file and that's by design. Files on disk are part of the project.

[tommck]

Ah, OK. Too bad for me. I always liked only seeing what files were going into TFS

[davidfowl]

Base on what was in the project?

[tommck]

Yeah. I only used "web site" if I was doing a non-MSFT tech project or basically static HTML. Otherwise, I used the web app and I liked not seeing files that weren't in my project.

[dennispg]

I agree with @Eilon that they should still show up in solution explorer, but the real issue is that .tfignore is ignored and asp.net 5 automatically adds files to source control and they show up in pending changes.

There needs to be a way to explicitly exclude files from version control.

Like #94 mentions, bower_components and node_modules are already ignored.

[tommck]

Well, when using things like "gulp" to build your project, creating one folder for "coverage", another for "dist", etc... It really screws up VS for me. If I search for a file, I get multiple copies.

Find/Replace in the "solution" picks up all these other copies of files too.

It's just not the desired functionality. So, unless I use folders completely outside the folder structure, it will consistently create these problems.

That's a step down in functionality in my mind. I should absolutely be able to hide folders from VS

[dennispg]

I think there are two different things involved here. Specifically regarding .tfignore, I dont think things in .tfignore should necessarily be hidden from solution explorer. That is something specifically related to version control.

You are absolutely right though, you should be able to also configure and hide folders or files from the project in solution explorer as well.. that's what something like what #94 mentions would do.

bower_components and node_modules are already hidden in this way, so there should be an additional mechanism (not .tfignore) to configure/unconfigure other folders or files to also be hidden in the same way.

This would both seem to be extremely common scenarios, I'm surprised there aren't more people complaining about it.

[breyed]

It is convenient to have .ts files transpiled to .js files in the same folder for easy debugging at dev time. But I don't want to check the .js files in. Worse, since TF is slow at processing file adds and removes (not checking them in - just tracking the changes), it slows down clean and rebuild, especially if there are many files. Operations with third party bower libraries get really sluggish, since there are so many files.

If you really want to wait, pull in DefinitelyTyped as a bower component. It would be nice if VS was architected to handle that volume of files.

[babeal]

+1 here! Typescript generated files and anything placed in the wwwroot is automatically added to the TFS check-in include list no matter what is in the tfignore file. I even tried _._ to ignore everything and it doesn't work. Previous posters mentioned that node_modules and bower_componets are excluded. Is this because of the exclude property in the project.json? If so, then why isn't wwwroot excluded. The only way I can think of to move forward is to turn off automatic typescript compilation and then have all my developers specifically exclude the wwwroot from TFS. However, i'm afraid of a person forgetting and then checking in all the compiled output. Is there another work around other than using git? Can we get this promoted to a defect with some type of resolution by beta 8?

[LifeguardConcepts]

We are also experiencing issues with the tfignore not being considered by TFS online specially for the wwwroot folder.

[babeal]

I am finally able to support a development workflow with ASP.NET 5 now that beta 8 has added excluded folders. However, we can't use the default flow with Typescript because the javascript files are generated next to the typescript files which are still automatically added to the changeset. At this time we are storing all of our typescript files outside of wwwroot and after build, copying them in place. This kind of works, however, when using ES6 modules which are path based we've run into issues with framework projects and are having to work around them.

[balachir]

ASP.NET 5 RC will have the ability to hide files from solution explorer. .

[tommck]

That just sounds like we're treating the symptoms rather than the problem. Having to add folders to both .tfignore _and_ excluded folders in the project.json doesn't seem like the _right_ solution

[dennispg]

I believe that if the file/folder is excluded using project.json, it would not then get added to source control automatically. @tommck, you shouldn't need to add to both .tfignore and project.json if you DON'T want the file/folder to be included in your solution. Someone correct me if I am wrong about that.

It is when you DO want the file/folder to be included in the solution that this .tfignore issue becomes relevant. This issue is very specifically for the problem of .tfignore not being honored by asp.net 5 projects, and the inability to exclude files which ARE in the solution from being checked into TFS.

That said, having the ability to hide files from solution explorer is great and is necessary. It is just that this is not what this issue is about. Rather, it addresses issue #94 and that is the issue which should have been closed instead.

I really think this particular issue should be reopened until .tfignore is properly honored..

[tommck]

I want it to be excluded from BOTH places, but the original problem still stands:

* The .tfignore file is not working. The files are added to "Pending Changes"*

Yes, this issue should NOT be closed @balachir

[dennispg]

@tommck, you wont be able to test excluding files till RC is available, but since Beta8 does include the ability to exclude folders.. have been able to test to see if excluding folders also excludes the folder from being checked into TFS? At least, that's the correct way it should work as far as I can tell..

It really seems to me that if you want it excluded from BOTH solution explorer AND source control, that you shouldn't have to worry about .tfignore at all for that specific use case.. just excluding from solution explorer should suffice.

Is that how you see it also?

[sayedihashimi]

Reopening for now. We are busy with critical release activities related to rc1 so we may not be able to investigate this right away.

[sayedihashimi]

@balachir do you know who owns .tfignore? Perhaps they should reply here.

[babeal]

So I installed RC1 today, prepared to move my entire development team to the supported release of ASP.NET 5, and now DnxInvisibleFolder no longer works!!! So now every time I build, 9000 files are added to my pending changes. This is completely unusable. Are there any tests run against TFSVC or only git? Do I need to create a MSDN support case to get this addressed?

Update: Turns out you already know it's a bug #289.

[tommck]

FYI: I now have RC1 installed and the problem still persists.

It's not a complicated situation. I have an ASPNET5 project. I use gulp scripts to build the HTML and javascript side of things (rest is APIs). The folders generated by the gulp scripts are in the .tfignore file. Every time I do a "gulp clean" and a "guilp build", the files all get added back to my pending files list (after locking up VS for quite a while while it deals with all these added files it's not supposed to be doing anything with)

I excluded the same folders from the solution and it changed nothing. They were actually even visible in the solution explorer after being deleted and re-built.

Unbelievably frustrating.

[ghost]

I also have this error - Can it be a tooling issue with Visual Studio with ASP.NET 5 ?

[tommck]

Our entire project team (30+ people) have this problem.

[ghost]

Steps to reproduce (TFS+VS2015):
Add logs files by making webserver log to web.cong:
1) <httpPlatform processPath="%DNX_PATH%" arguments="%DNX_ARGS%" stdoutLogFile="..\logs\httpplatform-stdout" stdoutLogEnabled="true" startupTimeLimit="3600"/>
2) Add a ".tfignore" file with the following:

*.log
logs\*.*

3) Run the application in VS2015 and notice that the generated log files are added to TFS regardless of the ".tfignore" file.

[mikes-gh]

Its a problem for me too.
I can find no way of excluding the bower packages in wwwroot/lib from tfs source control.

[dankellett]

We share the frustrations on this issue. wwwroot is essentially a client side "bin" folder, so it should never be checked into SC. Yes, I know about publishing and that is the real "bin", but wwwroot is a "bin" whilst developing and debugging locally. I urge to treat this issue with a higher priority, it really is getting in the way of developers and is not helping win over any naysayers of this new tooling.

[rolandoldengarm]

I have the same issue with a Cordova project. I've configured bower to put the libs into /www/app/libs, and added a line to .tfignore to exclude /www/app/libs. Does not work.

[ghost]

BTW: The title is misleading - this bug is not only about VS showing the files but also about the files being checkedin despite .tfsignore

[tommck]

@bluemmc just updated the title to try to express that better. Maybe it'll get more attention now?

[jrock2004]

Just adding my name to this as another person who is waiting for this frustrating bug to be fixed. People constantly checking in stuff that should not be is really frustrating

[joelbyrd]

This seems like such a simple feature, I'm surprised it's been an issue and hasn't been fixed yet. I share the frustration. I have to exclude a billion folders and files every time I check in - every. single. time. And I forget to include files I've added b/c that list is up to about 30,000 files.

[tommck]

Yeah. It's pretty crazy. It's been happening for about a year now. It wasn't a big deal when everything was alphas and pre-release software. Now, I find it rather disturbing that such a simple thing doesn't work

[balachir]

Thanks everyone for persisting with this. I am able to reproduce this with RC1 and have opened a bug for the issue in our internal bug database. We shall investigate the cause of this issue and let you know.

"183569: Entries in .tfignore still get added as pending changes for ASP.NET 5 project with TypeScript file #18".

[gokussx4]

Just wanted to add this happens to me with nuget packages. When you run an update those packages (even with packages in the .tfignore) will show up as pending changes. Like everyone else, waiting patiently :)

[jonathansotoan]

Also waiting patiently for this issue to be solved

[tommck]

I'm waiting a bit more impatiently than most

[GregoryOtt]

Have you any date for a hotfix?

[eriksendc]

FYI, I brought up this issue to the ASP.NET Community Standup and followed up with an email to Scott Hanselman this morning.

[shanselman]

I'm looking at this.

[jpblancoder]

I have Visual Studio 2015 with .tfignore file with: \node_modules
Many of the 25 modules within that folder are always successfully ignored by VS, when re-opening the solution, and not listed in Pending changes. Here are 5 modules that are always not ignored, and added to Pending Changes when re-opening the solution after placing them in the node_modules folder. I believe that long path lengths _may_ be related to a module being not ignored. I hope this is useful for any testing. Thanks.

Not ignored modules:

C:\TFS\Dashboard-CCOD\CCODApplication\node_modules\gulp-bowserify
C:\TFS\Dashboard-CCOD\CCODApplication\node_modules\gulp-clean
C:\TFS\Dashboard-CCOD\CCODApplication\node_modules\gulp-karma
C:\TFS\Dashboard-CCOD\CCODApplication\node_modules\gulp-uglify
C:\TFS\Dashboard-CCOD\CCODApplication\node_modules\gulp-usemin

File location of .tfignore:

C:\TFS\Dashboard-CCOD\CCODApplication\.tfignore

[eLarocque]

This is a big issue for us as well.
It has put a damper on our plans to go forward with .NET Core for some of our projects.
Hoping a fix is coming soon...
Thanks.

[FloMaetschke]

We have the same problem here. We just want to ignore a few folders in tfs which are automatically filled with files from gulp tasks.

[jonathansotoan]

@FloMaetschke that's also my pain right now (but in my case, it is with grunt). What I'm doing right now is excluding all those generated files before checking in. A solution I'm thinking to implement as soon as I have some time is to create a task that excludes all those files with tf.exe (I don't know what command I'm going to use yet).

[garcus]

+1
This is truly painful. I don't have the option to switch to Git (where this is not an issue).

[dotnetautor]

+1
Please fix the behavior for .tfignore in ASP.NET 5 projects using grunt or gulp.

[FloMaetschke]

@shanselman Is there already a fix in the pipelines?

[johnnyPescarul]

Adding my support to prioritize this issue. It is extremely annoying and unproductive. When you run the gulp task to generate the .js from .ts files it hangs (trying to re-add the folders, even thous they are ignored) and slows down the build significantly.

[arnaudmaichac]

+1
Same issue here when using Gulp, files generated by Gulp are automatically added to source control

[frenchyjef]

If you are using an .xproj and want to hide folders or files from your solution explorer, an alternative to .tfignore could be to add the following section of code inside your .xproj file:

  <ItemGroup>
    <DnxInvisibleFolder Include="bower_components\" />
    <DnxInvisibleContent Include="bower.json" />
    <DnxInvisibleContent Include="package.json" />
  </ItemGroup>

As a result, those files/folders are hidden from Solution Explorer and will NOT be added to your source control as well.

[babeal]

@frenchyjef - are you positive? Please see issue #289 -> this was confirmed broken in rc1. Thats why im still on beta 8.

[frenchyjef]

I would love if someone can confirm this as well before you upgrade but it does work for me.

This is my computer configuration

Microsoft Visual Studio Enterprise 2015
Version 14.0.24720.00 Update 1
Microsoft .NET Framework
Version 4.6.01038

Installed Version: Enterprise

ASP.NET and Web Tools 2015 (RC1 Update 1) 14.1.20203.0

And here is a screenshot after the DnxInvisibleFolder code was applied

[babeal]

@frenchyjef can you try any other folder other than bower* or npm_modules? They are special folders and have special handling.

[frenchyjef]

I added

DnxInvisibleFolder Include="wwwroot\css\"

and the folder disappeared from Solution Explorer:

[babeal]

@frenchyjef So i just tested it, it seems to also honor things in wwwroot to some extent. But outside of wwwroot, i excluded the folder "build", then reloaded the project, then mkdir build, it shows up in my souce explorer. Then echo "test" >> test.js in the build folder, that file also appears, and both items are listed in my pending changes list. I was also able to get wwwroot/css to reappear but I'm not exactly sure what's the on off switch for those files.

[JamesReate]

In my .xproj I have:
<DnxInvisibleFolder Include="wwwroot\dist\" />

But when I run gulp build it still tries to add this folder to source control causing VS2015 to hang and sometimes crash. Switching to Git for the time being isn't an option.

[eriksendc]

@frenchyjef - The hiding of folders is one thing but the point of .tfignore is to keep files from being candidates for checking into TFS version control. DnxInvisibleFolder only keeps the folder from showing up in solution explorer, but each and every time one has to keep excluding folders from being checked in in the pending changes window.

[FloMaetschke]

@frenchyjef I totally agree to @eriksendc . It makes a difference to just hide a folder in the solution explorer or to exclude files/folders from tfs permanently.

I would prefer to see a "build" folder in the solution folder, this makes it easy to check the output files etc. but i don't want them checked in to tfs.

[JamesReate]

Agree with @eriksendc , having .tfignore actually work would be the best solution so we could just have a .tfignore file in the root with:

\node_modules
\wwwroot\dist
\wwwroot\jspm_packages

[babeal]

...the only reason I commented was that DnxInvisibleFolders was supposed to help patch this issue for the interim, and in beta 8 it did just that. I was able to build into a build folder and then copy what was needed into wwwroot which also used invisible folders. In RC1 this broke and on dec 4th I wrote a not very nice comment on this issue. This is because I am still stuck with my entire development team on beta 8, which currently isn't being used for anything other than a static file server. Git somewhat fixes this but if I go git then I might also go "the app container that shall not be named".

[JohannesHoppe]

+1
We assumed that the RC would be somehow stable. We were so much wrong; it should have been named beta-9. This damn bug is just embarrassing and slows down the full team. We highly regret our update from MVC5 to 6.

By the way, this bug has number 18 and it is still not fixed?! Shame on you!

[ryanlangton]

In one week it will be a year since this bug was submitted. I think Microsoft is saying loud and clear that we should not be using TFS for source control. I know I won't.

[rolandoldengarm]

It didn't make it to the latest update to Visual Studio, VS 2015 Update 2 RC: https://blogs.msdn.microsoft.com/visualstudio/2016/03/03/visual-studio-2015-update-2-rc/
:-1:

[tommck]

Yeah, this is kind of embarrassing, in my opinion.

[bmbell]

+1

I would think that we would want to ignore many things in the wwwroot directory since they get generated or copied from various areas of the project. How is this not a critical use case?

[sayedihashimi]

Hi everyone, I'm working with the team that owns this aspect of source control integration to try to get this resolved. I will ask someone from their team to provide an update here.

[JohannesHoppe]

@sayedihashimi Do you have some news for us?

[manfredsteyer]

@sayedihashimi I would also need a solution for this. Currently, this small issue is quite a show-stopper for us ...

[jezmck]

Any update?

[jasonhjohnson]

+1

[bobwah]

+1

[Andreas-Huber]

Temporary quick fix / hack for the problem:
Simply add an $ char into the bower_components folder name in the .bowerrc. TFS does not allow the $ character in the file name, so it can't be added to source control.

This is also working for folders in wwwroot. So for now i will use a $dist folder to drop the compiled typescript files etc. Not the nicest solution, but I'm fine with that for now.

Example for the .bowerrc:
{ "directory": "$bower_components" }

[JohannesHoppe]

@Andreas-Huber Many, many thanks! :smile:

[tommck]

@Andreas-Huber inventive answer. Thanks for posting it. Really hope they will fix Visual Studio before I grow old and die, though

[sayedihashimi]

Hi everyone, I have had a few more conversations internally and have an update for you.

We have worked with the VS Source Control team on this issue for the past several months. We have investigated what it would take to improve this scenario. The changes were too large to get into VS2015 Update 2. We are hoping that we will be able to improve this in Update 3, but we have not received a firm commitment on that yet.

First let me explain the root cause of this issue. The ASP.NET Core/5 project system monitors files on disk and sends file/folder events to the source control provider. For example, when a file is added to the project folder the project system will add that file to the project, show it in Solution Explorer, and send an add file event to the source control provider. This happens so that we can provide the “include all files in project folder” experience. In an ASP.NET 4 project after adding the file to the project folder users would need to explicitly add that file. When using TFS in some scenarios the .tfignore file is not used. The .tfignore feature was designed before the ASP.NET Core/5 project system and was not designed to work well with projects that “include all files in project folder” like ASP.NET Core/5 does.

Regarding Git provider's handling of .gitignore, a different implementation was chosen in order to be consistent with other Git tools and the Git community's established .gitignore behavior. Git provider was also a brand new codebase without the chains of legacy compat/behavior concerns that accumulate as releases come and go.

We will continue to work with the VS Source Control team, to see if we can improve this for Update 3. Once we have more info I will be sure to share that here.

[tommck]

Thank you for the detailed update Sayed. It shows that you've been working on it.

However, I can't stress my disappointment enough. I've been dealing with this insanely painful bug for almost 17 months (didn't report it for 5 because I assumed it was a pretty common bug that you'd fix early on).

I honestly am astonished that this hasn't been a MUCH higher priority than it seems to be.

Will we at least be able to get a hotfix or something? It's insane to have to wait for an entire new update for this

[mikes-gh]

I am starting to think since aspnetcore is cross platform that github is perhaps better home anyway.
The thing is once I start using github for my aspnetcore projects I may as well put all my other projects there as well to save me having to work in 2 different ways.

But maybe MS does see github as the future.... It would be nice to know for sure.

[JohannesHoppe]

Based on that embarrassing experience, I would say that TFS is not any longer are core product at all. That dubious “VS Source Control team” must have been downsized dramatically. In other words: that single guy who is doing the maintenance is still searching for the damn bug.

[dennispg]

I can understand the frustration over an issue that seems so basic on the face of it. I can even share in the frustration over how long it took to acknowledge that this was an actual issue...

But I'm really curious to understand the reasoning and wisdom in the decision to use a foundational framework like this in a real life production scenario while the product is still in alpha/beta/pre-release stage.

[tommck]

Well, when you're on a multi-year development project, it's pretty stupid to start with technology that you know is going away. So, I think it's wise to use the new stuff rather than the old.

[mikes-gh]

@dennispg We should be thankful there are people working with real world projects at this early stage. Without their feedback we are only using the framework against samples and tests which even if coverage is good is never going to surface the real world issues which can then be addressed before shipping.

[sayedihashimi]

Hi everyone. I want to assure you that the TFS team is healthy and it is a core part of our product as it has been since it was first released. The reason why you're facing this issue is completely my fault. I underestimated the amount of people that this would impact and the frustration that it would cause, so I didn't follow up with the appropriate teams to get this resolved in a timely manner. Now it's very clear to me that I should have been pushing on this for quite some time. I apologize for that and will try and do a better job going forward on that.

Some more context. When creating ASP.NET Core/5 we redesigned fundamental items in the project system. For example, including all files in the project folder, and many other significant changes. When you do that into an existing product that has been developed for 20+ years it's not possible to enable all scenarios on day 1. We have to pick the right set of features to start with and then incrementally build on those. In this case I underestimated the impact this would have and the support wasn't in the correct priority to get it addressed before now. I have reached out again to the team that owns this for an update. Right now the item is under investigation, with the possibility of getting some updates for Update 3. Since this would require feature level changes that investigation may take some time. I'm going to check back with that team in 2-3 weeks to see how the investigation is going and see if we can improve this for Update 3. I'm really hoping that we can improve this for Update 3. I'm not at a point where I can tell you with confidence that we will, but this is on the top of my list and I will be following up on this item. Once I get an update, I will update this thread.

[tommck]

Thank you Sayed

[jvelezc]

1+ I just hit this issue when creating an automated build for TFS... for a real world project. Thank you all for bringing this up many months ago so that my team doesn't have to wait that long.

[tommck]

Hopefully we don't have to wait another year for it to be resolved

[tommck]

Hey @sayedihashimi, any chance you can check with the team to get an idea of when the pain will end?

[sayedihashimi]

@tommck I'm meeting with them in the next few days actually.

[Aanhane]

Please let us know how it went, I think more and more people will face this problem as more ASP.NET Core projects are added to TFS. An estimate on when it will be fixed, would be great.

[sayedihashimi]

Here is an update.

I met with the PM owner for this particular experience. I reinforced how important .NET Core is and the history of how it came about.

He let me know that they are currently investigating this. He also stated that to get support for this we will need to make changes to a low level TFS/VS component. So the required changes could potentially destabilize the entire TFS/VS experience, and would require a good amount of testing.

I've asked that we try and get this in for Update 3. He should get back to me in a few days regarding feasibility of achieving that goal. Once I hear back from him I will reply back here.

[LifeguardConcepts]

@sayedihashimi, thanks for the update.

I'm still pretty shocked that was not given due oversight from the very beginning of Core given A.) Its Microsoft Team Foundation Server not some 3rd party product B.) TFS as a provider and as a product for MS is still priority product and used by major/minor/government organizations. C.) Its a major rewrite core components. How does something like this go unnoticed?

I thank you for the time you have put against this even though its not directly your issue. Would be great to the have the PM owner participate rather then have you relay information.

[rolandoldengarm]

@sayedihashimi Thank you for the update. Still pretty surprised that it is still being investigated, and not fixed. Just looking at this high level this is such basic functionality.
And indeed, the PM should be posting updates here, not you.

[jvelezc]

I build a hack around it. But man... it was a lot of work.

[dankellett]

Considering the changes going on in in the tooling for corefx RC2: dnx/dnu/dnvm to dotnet, I'm now not surprised this hasn't been made a priority. That being said, I'd like to see this bundled with the tooling updates.

[tommck]

Thing I find weird is that this affects pretty much a mainstream method of building modern websites.

People use task runners like gulp & grunt to build their apps. How was this not part of the baseline testing for the tooling?

At this point, I'm only using Visual Studio for TFS integration and doing all my editing outside of VS because of how slow it gets when files change on disk. It's really amazing. This is the first version of VS that most of our devs have ever used and they're just laughing at how bad the experience is and longing for their days of using Eclipse, which is just sad.

[rolandoldengarm]

@tommck +1
We've switched to Visual Studio Code + Angular 2 and removed ASP.NET Core MVC from our project, just because of this.
I'm using Visual Studio Power tools for TFS, would only need Visual Studio for file compare.
https://visualstudiogallery.msdn.microsoft.com/898a828a-af00-42c6-bbb2-530dc7b8f2e1

[JohannesHoppe]

Same here, we do dnu web and keep Visual Studio closed all the time during development. The "$ in front"-hack works, but VS is so unbelievable slow... Worst Microsoft-experience we ever had. Some years ago a RC candidate was somehow usable. But this is just embarrassing now. TFVC is dead technology, everybody should switch to GIT.

[bbsimonbb]

For me, a minimum requirement would be a concise statement of the problem. I'm just getting started with .tfignore, in a project using the empty web application template, in VS2015. .tfignore doesn't appear to have any effect, but I don't know if this is due to this problem, or something else.

[sayedihashimi]

I met with the TFS team today to discuss this issue and I have an update here.

We have investigated multiple ways to solve this problem. The ideal solution is to make .tfignore work exactly as .gitignore does. That would mean to bring ignore processing to server workspaces. This would require extending existing contracts and it has the potential to destabilize the entire TFS experience. We thought that would be too risky, especially for an install going into VS Update. So we started looking at other options.

The fundamental issues here is that both the project system (.xproj) and the VS Source Control provider is raising add/edit events for source control. In this case when the project system calls Add File, the .tfignore file is not examined to ensure that the file shouldn't be added. Effectively to the user the .tfignore file was not used.

To solve this we are planning to update the logic when a file is added to source control. For this particular case, when a file is added the Source Control client will look to see if the file is matched in .tfignore. If the file is matched in .tfignore the file will not be added.

For the case where you want to explicitly add a file to source control which has been ignored you can Right Click and select Add To Source Control. You'll be prompted to confirm since it's ignored.

For the case of multi-selecting files there are two cases.

1. All files are listed are ignored
2. Some files are listed as ignored and others as not ignored.

For 1: since all the files are ignored you'll be prompted to confirm adding the ignored files.
For 2: we assume that you meant to add the files that are not listed in ignore and leave the rest as is. You'll need to specifically select ignored files.

There is also one more caveat here. When .gitignore is used, for ignored files you'll get a red glyph on the icon indicating that the file is ignored. This is possible by having the ignore processing on the server side. With the ignore processing happening on the client side adding this glyph is not feasible.

We are hoping to ship these changes in VS 2015 Update 3. Additionally we are targetting VS2015 Update 3 Preview 1, which is the first public preview of Update 3. The team is currently finishing up the dev work here and it will enter verification soon. We are pretty confident that this will make it into Update3, and in the Preview1, but there are some chances that we may find something during verification that could delay this. If we find anything that would cause this to get delayed I will let you know right away.

[rolandoldengarm]

Thanks for the update :+1:

[tommck]

@sayedihashimi How can I test that Preview when it's out? I volunteer wholeheartedly to test that :)

[sayedihashimi]

@tommck the first time you can try it is when VS 2015 Update 3 Preview 1 is released (assuming all goes well of course).

[JohannesHoppe]

destabilize the entire TFS experience

Sorry, but this has already happened!

I don't understand the implications of such a .tfignore file. It should provide a list of patterns that must be ignored. In my eyes this feature is fundamentally broken. Why don't you fix the root cause of the problem?

[dankellett]

"Ideal solution" != "fixing the root cause"

To me it sounds like their solution will work just fine.

[BasPaap]

Having to wait for the preview is one thing, but having to wait until update 3 is final is going to take months. I'm sure there are many developers out there who can't (or won't) use the preview versions of updates, and also can't just put their projects on hold for half a year or so. So while we wait for update 3, is there a workaround we can use to get TFS to ignore certain files?

[rolandoldengarm]

@BasPaap put them in a folder that starts with $ is the only workaround I know off.

[uxp]

For 2: we assume that you meant to add the files that are not listed in ignore and leave the rest as is. You'll need to specifically select ignored files.

@sayedihashimi IMO, this should act exactly the same as if you are copying or moving a directory in Windows Explorer to another folder that already contains a directory of that name. It should successfully add the files that are not duplicates (matched in .tfignore), and prompt to overwrite or retain the existing (confirm to add despite an ignore match). It _sounds_ like you described a silent failure when adding multiple files to source control when some might be matched as ignore. I hope this is not the case.

That said, I'm anxiously waiting for this fix to hit the pipeline. Thank you to everyone that's contributed to this issue. I just switched to developing on Windows from almost a decade of developing for the web and mobile on a Mac or Linux box with SVN or Git, and I'm absolutely shocked at the number of subtle expectations that Windows developers are supposed to follow and conform to just because their tools don't support anything else. I shouldn't have to wait until the seven moons of the solar system align before a file's expected behavior gets honored. All complaints aside, my team can develop a hacky workaround to get around this issue for the time being. Thank you.

[mikes-gh]

@uxp if your from a git background I'd stay with that, I just moved all my code from visual studio online tfs to bit bucket so I'm going the opposite way to you. I have to say git is a revelation for me. Visual studio has a pretty good git client these days too. Besides the various issues in this thread I always ended up with a huge ignores list and I could never delete erroneous projects from Tfs. I also have the security that I can move my project with its history intact to another provider easily.

[uxp]

@mikes-gh I may be from git, but I can't magically convert my entire team to git as easily as just waking up and doing it.

TFS has benefits for many reasons. This just happens to be not one of them ;)

[bburman]

@sayedihashimi Would a hotfix be an option? I know that many of us would be willing to accept the risk of destabilizing our TFS experience if it could just get us to Update 3. If not, can you perhaps outline some hacks or workarounds that can get us to that point? Would it be possible for us to write a custom Visual Studio extension that could correct the issue on our end?

[IAMtheIAM]

Amazing that such a basic feature (ignoring check-in of file/folder) does not work in the 2015 edition of visual studio. Are we living in 1990?

[Boogier]

waiting for a fix...

[hobe]

Unfortunately this issue is an absolute showstopper for our project (Angular2+asp.net core+VSTS) it's very frustrating that such essential features aren't fixed at this state of the whole asp.net core project.

[DaEkstrim]

I really wish there's at least a quick fix to this issue. Each time that the task runner is invoking grunt build tasks, the TFS client is going berserk and increasing build time considerably while trying to inform the TFS server that 6,000 files have been updated/moved/deleted or renamed. Not to mention the insane number of errors generated in the Output window because the files from the previous build are still checked out.

[shanselman]

The new behavior is in VS2015 Update 3 (now as a RC, coming soon, perhaps in a day or so?) @sayedihashimi

[sayedihashimi]

Yes it's coming out soon. My team verified the changes and they look good. I'm not sure the exact release date.

[BasPaap]

How is that "soon"? We run production software here, not betas or release candidates. If the team is not even sure of the RC's release date, then that must mean the final version is still months out. Which means many, many more months with this absolute showstopper of a bug. Unacceptable. At least provide a hotfix for this particular bug.

[bburman]

Thanks for the update @sayedihashimi. Simply cloaking the dynamically generated directories in TFS has been an acceptable workaround for my team. It's a little tedious to set all of the mappings up on each of our machines, but it is working for us, nonetheless.

[hobe]

It works in Update 3 RC! :+1:
https://blogs.msdn.microsoft.com/visualstudio/2016/06/07/visual-studio-2015-update-3-rc/

[DaEkstrim]

Update 3 RC: I might need to analyse this further, but preliminary analysis is showing that if I run a grunt task during runtime, the output window is still showing TFS client error entries on folders that are in the .tfignore. However they are not showing up in the Pending Changes (which is a good thing). Performance has definitely improved.

[jimbuck]

Update 3 is live!

[Tenmak]

Using VS 2015 RC3 and gulp, the .tfignore is indeed working correctly for me as well. Cheers !

[delie]

Unfortunately, the implementation is still buggy. "Source Control - Team Foundation" output moans about files which it shouldn't care about in the Output window.

For instance..

1. Add some files to a folder
2. Add that folder to .tfignore
3. Delete one of the files
4. You'll see a line appearing in the Output window, which then grabs focus and takes you away from anything else you were looking at at the time.
5. Add new files, repeat, same thing happens - so it's not just files that previously existed.

Example output:
_The item C:\Dev\test\src\tester\wwwroot\build\polyfills.bundle.js could not be found in your workspace, or you do not have permission to access it._

Well, yes.. correct...it doesn't exist anymore, because we deleted it, but TFS shouldn't care about this because wwwroot\build is in my .tfignore file

[tommck]

Well, better late than never. Yes, there may be another bug or two, but I'm going to close this issue, since it is finally doing mostly what is needed. Perhaps folks will need to create a new issue for the new problems with the Output window errors.

[delie]

Ok, fair enough. I've created a new issue for the output window bug here: #661

[airomero]

Hi, i'm using VS2015.3 Enterprise. I'm working on an aspnet core 1.0 project. I have a .tfignore at the root of my web project that look like this:

wwwroot\css\themes
wwwroot\npm

When i go to pending changes both folders are always there to commit to VSTS. IS this a bug or am i doing something wrong?

Thanks

[LifeguardConcepts]

@airomero. You are not doing anything wrong. Instead of fixing the issue at the provider level they fixed it through VS Tooling which is version specific so you may not get the fix. It's also the reason why it's still showing in the output window.

In honest opinion it was a quicker fix but not the proper one.

[airomero]

So why is this closed?? If it was through vs tooling, what should i install to get it working. It is such a basic requirement, this should be fixed. And also this issue should not be closed.

[LifeguardConcepts]

You are on vs 2015 with update 3 so it should work...

[airomero]

It doesn't work. That's why i'm asking if i'm doing something wrong. i just put the .tfignore in the root of the net core project with the paths:

wwwroot\css\themes
wwwroot\npm

But both still are in pending changes every time i want to do a check in.

[JauernigIT]

If they are "still" in pending changes, first create a backup copy, then make an Undo on them. Close VS, restore the backup copies and then it should work (cumbersome, but worked in our project).

[delie]

@airomero - Do you have an RTM or CTP version of VS 2015 Update 3? Are you sure you're using the full release version?

[tommck]

I closed it because I was the one who opened it and the problem I reported was fixed. the .tfignore file is working fine for me.

[Tenmak]

@airomero Maybe the problem comes from your .tfignore file itself as well...

Mine looks like this :

# Ignore all files in the corresponding subfolders :
\app
\node_modules
\app_themes
\css
#
# Do not ignore folder \js !
!\js

[airomero]

Solved. @JauernigIT based on your answer, I deleted the entire solution from my disk, downloaded again from VSTS and then it worked. Apparently the problem is that the folders I want to ignore must be created after the .tfignore exists.
When it didn't work I created the .tfignore after the folders and its content were created. So, first .tfignore and then folders. Weird.

[JauernigIT]

Yeah, when you add a file/folder first and TFS/VS then has it in Pending Changes, it doesn't get it out of there when you add a .tfignore. I'm not sure if it's a bug or a feature ;-)

[delie]

I don't think you can call it a feature. If it was a feature, the gui would highlight the fact that you've excluded something that is already pending, or even already checked in, and then prompt you to decide what to do. That would be a feature :)

To be fair, .gitignore files work in exactly the same way.

[RezaRahmati]

I have same issue VisualStudio2013 + Tfs2017
http://stackoverflow.com/questions/42537053/tfignore-is-not-ignoring-files

[weitzhandler]

I'm also having this issue in VS 15.4.

After adding /.vs and /.vs/* to the _.tfignore_ file, that folder still appears under 'Pending Changes'.
How do I exclude that folder for good?

[barrytang]

To report new issues, use the Report a Problem tool. The GitHub Issue Tracker for the aspnet/Tooling repo is now deprecated in favor of the Report a Problem tool.

If you encounter a problem with Visual Studio, we want to know about it so that we can diagnose and fix it. By using the Report a Problem tool, you can collect detailed information about the problem, and send it to Microsoft with just a few button clicks. See here for more details.