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.

[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.

[ghost]

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.

[ghost]

@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.

[ghost]

@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