For instance a temp folder storing intermediate output from a grunt build. node_modules
and bower_components
are automatically excluded, but it doesn't appear to be configurable. exclude
in project.json has no effect on VS.
As a result, VS will hang trying to keep up with all the file and folder changes.
This was using a project.json project using one of the beta versions of the asp.net tooling.
@billhiebert any ideas?
Only solution is to create shorter paths. which usually means placing the project near the root of the drive. Unfortunately, windows is limited to 250 characters and the node tools create very deep paths.
That is a problem, worthy of its own issue #.
My issue is that I can't exclude a folder from the project. The tooling knows to ignore node and bower but doesn't appear to be configurable
Just an update.. it seems RTM no longer automatically excludes bower_components
.
This definitely needs to be configurable..
@da1rren You are wrong. RC did definitely exclude bower_components
and both RC and RTM still do exclude node_modules
from ASP.net 5 projects right now. You can see it for yourself if you just take a look.
And more importantly, @BillHiebert and @sayedihashimi, please note that the 260 character limit issue is a totally separate thing from the problem highlighted in the OP, worthy of it's own issue as @BradBarnich said.
This issue is highlighting the critical need for a configurable method to specify folders to not be automatically included within an ASP.net 5 project. The use case has already clearly been shown as necessary to handle intermediate output from gulp/grunt tasks. The exclude
element in project.json would make sense to allow for this, but it currently does not function in this way.
Issue #18 also highlights the very distinctly different but equally important need for items to be included in the project, but not automatically checked into source control. For that, the .tfignore
file should already enable that, but ASP.net 5 projects do not respect it.
Ever since upgrading from Visual Studio 2015 RC to 2015 Release, this issue has been causing me substantial frustration. My app is written in TypeScript and I use tsd to automatically manage and update my declaration file dependencies. I use bower to pull in packages like angular-ui-router which comes with an out of date, barely documented .d.ts file. Since I cannot seem to tell VS to ignore the bower_components folder, go to definition always takes me to the wrong version of the file. It also causes the TypeScript compiler to error due to conflicting declarations of the same module.
I setup a custom clean task which removes type definitions brought in by bower packages, but there are other issues with not being able to exclude this folder from VS. Anyway there needs to be a way to configure this kind of thing.
I've been able to exclude folders from source control by adding a cloak to the folder in TFS since the .tfignore file doesn't work but the issue then is it CONSTANTLY prompts me about "You are attempting to add an item to a source-controlled project, but the item's path has no mapping...." It does this because I have a gulp watch running for when we change the client files (angularjs project) and we copy them to the wwwroot folder.
The .tfignore problem needs fixed either that or give me the ability to turn off the frustrating source control dialog.
A workaround for this issue.
Ofcourse, it's absolutely nuts that this is necessary but it has allowed me to move forwards - my issue is that I am using jspm
rather than bower
for my javascript dependency management - and this has added a `jspm_packages' folder to the project which I do not want included.
Incidentally the 'node_modules' folder is excluded from the project in Solution Explorer and I assumed this was due to the exclude
section in Project.json
. So naively, I added an entry for jspm_packages
. I am guessing I am not the first person to make this mistake, or the last.
Thanks for the feedback everyone. This is a known issue and we have a backlog item to address it. I'm hoping that we can get that in the next public release, but we are not fully committed to that yet.
Thanks sayedihashimi for responding. Could you tell me what issue the backlog item addresses? Does it address only the exclude section or also TFS not adhering to the tfignore file?
Is it not as simple as adding something like the following to the xproj?
<ItemGroup>
<DnxInvisibleFolder Include="wwwroot\jspm_packages\" />
</ItemGroup>
@dougludlow When you right click a folder within Solution Explorer and then click "Hide from Solution Explorer" the following is what gets added to the xproj file by VS.
<ItemGroup>
<DnxInvisibleFolder Include="bower_components\" />
</ItemGroup>
However, VS just keep showing that folder within the Solution Explorer.
Do you have Show All Files enabled in Solution Explorer? If so, toggle it.
@sayedihashimi You are right. Toggling the switch helped me get rid of the bower_components folder within Solution Explorer. What confused me was having node_modules
folder with a distinctive icon but not the bower_components
. Do you think you should update any hidden folder's icon just like you do for the node_modules
folder? Then we would know that the folder is now hidden but it is being displayed because I have the "Show All Files" toggle on.
By the way, the Pending Changes pane still does not ignore the changes in the bower_components directory. I get the auto generated files added to TFS even though I would prefer them to stay out.
Can you attach a screen shot? In away from my computer. For the pending changes we are tracking that.
So, bower_components
and node_modules
are the hidden directories. I can differentiate node_modules
because it has a different icon but the bower_components
directory has a standard directory icon.
The same goes for bower.json
and config.json
files. bower.json
is actually hidden from VS and gets hidden when Show All Files
is toggled off. However, it is impossible to differentiate bower.json
being a hidden file.
I don't have any of the previous VS releases so I cannot compare but as far as I can recall, previous VS releases had a way of clearly displaying custom hidden directories and files with different than standard icons. Changing the opacity of standard icons was the way they went if I am not wrong.
Let's see what @madskristensen says.
Alright.
By the way, one of the biggest problem with not being able to completely hide a folder is that VS tries to update the _references.js
file too often and that causes a performance issue with the responsiveness of VS. I cannot find any other way than killing the VS process and reopening the solution very often.
I'm bumping my support for this. Trying to do anything with bower is a complete pain because it causes visual studio to slog through thousands of files. The only recourse I've found is to move the bower_components
folder inside node_modules
, since the node_modules
gets treated special.
Even hiding the bower_components
folder doesn't stop this. Tools still analyze the files in the hidden folder, etc. only node_modules
gets properly "excluded" from everything.
@ciel Perhaps not exactly helpful to your situation, but have you tried using this instead of Bower? https://visualstudiogallery.msdn.microsoft.com/4cd5e0e0-2c38-426b-9f43-1d3688cc8be1
That's a really neat extension, but I've already invested a lot of time and
structure into bower.
On Feb 29, 2016 10:40 AM, "Mads Kristensen" [email protected]
wrote:
@ciel https://github.com/ciel Perhaps not exactly helpful to your
situation, but have you tried using this instead of Bower?
https://visualstudiogallery.msdn.microsoft.com/4cd5e0e0-2c38-426b-9f43-1d3688cc8be1—
Reply to this email directly or view it on GitHub
https://github.com/aspnet/Tooling/issues/94#issuecomment-190281619.
@sayedihashimi I don't think _bower_components_ should be hidden, but it should not take down VS when installing hundreds or thousands of files.
Ideally, I feel we should be able to exclude any folder from the solution.
Though I'm unsure how reasonable a request that is.
On Feb 29, 2016 10:42 AM, "Mads Kristensen" [email protected]
wrote:
@sayedihashimi https://github.com/sayedihashimi I don't think
_bower_components_ should be hidden, but it should not take down VS when
installing hundreds or thousands of files.—
Reply to this email directly or view it on GitHub
https://github.com/aspnet/Tooling/issues/94#issuecomment-190282240.
@madskristensen there should be a new issue opened for the problem of visual studio coming to a crawl when many new files are added..
but this issue is specifically for enabling a configurable means to hide bower_components or any other folder
I'm not sure I would say software slowing down when 3000+ huge files are
added to it suddenly is a fair issue to ask to fix. It's unreleased to
expect Visual Studio, or anything, to handle that gracefully. That's why I
just wanted the option to hide a folder.
On Feb 29, 2016 10:51 AM, "dennispg" [email protected] wrote:
@madskristensen https://github.com/madskristensen there should be a new
issue opened for the problem of visual studio coming to a crawl when many
new files are added..but this issue is specifically for enabling a configurable means to hide
bower_components or any other folder—
Reply to this email directly or view it on GitHub
https://github.com/aspnet/Tooling/issues/94#issuecomment-190285221.
There is even an exclude
parameter in the project.json, but at the time it was not respected by the dnx Visual Studio tooling. The default is bin/**;obj/**;*.kproj
, this seems the the right property to be setting.
This seems like a trivial fix, can anyone from the team comment if this will be fixed for RC2?
It was a complete showstopper for my organization's use of asp.net core.
Got it, they are two separate issues. I'm pretty sure that excluding files and folders from the project is coming. Right now it's hard coded only to hide _node_modules_ AFAIK, but I believe that is being made generic soon. @sayedihashimi might know if it will be ready for ASP.NET Core 1.0 RTM?
I am really confused about the state of the tooling. From all the issues I see, and the way they are responded to and discussed, it seems like there is work being done on it. But there hasn’t been a commit to the repository in over two months, and there are no other branches. Is the tooling done somewhere else?
@ciel Yes it is confusing. The Visual Studio tooling is done internally and not here on GitHub. This repro is mainly for raising and discussing issues.
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" }
Excluding folders from source control isn't the problem. That can be done
with a .gitignore. We need them excluded from Visual Studio itself.
On Mar 12, 2016 8:34 AM, "Andreas Huber" [email protected] wrote:
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.[image: excludefromtfs]
https://cloud.githubusercontent.com/assets/13376471/13723476/04c99eb6-e867-11e5-8c55-94c498c7ac0f.pngThis 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" }—
Reply to this email directly or view it on GitHub
https://github.com/aspnet/Tooling/issues/94#issuecomment-195750462.
@ciel But for TFS users it is a problem to exclude it from soruce control. The .tfignore simply does not work in ASP.NET 5 projects.
Hiding it in the .xproj
file worked for me. But i have no need to remove it.
<ItemGroup>
<DnxInvisibleFolder Include="$bower_components" />
<DnxInvisibleContent Include="bower.json" />
<DnxInvisibleContent Include=".bowerrc" />
<DnxInvisibleContent Include="package.json" />
</ItemGroup>
That's fine, but that's really not the purpose of this thread. It might be
wiser to start one specifically for that since it has nothing to do with
what we're asking for.
On Mar 12, 2016 8:49 AM, "Andreas Huber" [email protected] wrote:
@ciel https://github.com/ciel But for TFS users it is a problem to
exclude it from soruce control. The .tfignore simply does not work in
ASP.NET 5 projects.
Hiding it in the .xproj file worked for me. But i have no need to remove
it.
—
Reply to this email directly or view it on GitHub
https://github.com/aspnet/Tooling/issues/94#issuecomment-195752782.
It's more likely to attract the attention of people that care about that
specific functionality that way.
On Mar 12, 2016 8:50 AM, "Stacey Lynn" stacey.cielia.[email protected] wrote:
That's fine, but that's really not the purpose of this thread. It might be
wiser to start one specifically for that since it has nothing to do with
what we're asking for.
On Mar 12, 2016 8:49 AM, "Andreas Huber" [email protected] wrote:@ciel https://github.com/ciel But for TFS users it is a problem to
exclude it from soruce control. The .tfignore simply does not work in
ASP.NET 5 projects.
Hiding it in the .xproj file worked for me. But i have no need to remove
it.
—
Reply to this email directly or view it on GitHub
https://github.com/aspnet/Tooling/issues/94#issuecomment-195752782.
I literally just ran into this issue locally, it looks like the xproj is trying to dig into some node_modules that I don't want it to.
I've tried adding InvisibleFolder, but it doesn't seem to impact anything-- I still have to wait for VS to sit on a full progress bar and white screen for about 15 seconds before I see this:
VsProjectFault_57bc31b3-c52f-4613-afde-67fdeb79cc9e.failure.txt
I've tried adding this side by side with my other ignores:
<DnxInvisibleFolder Include="pylon-gulp" />
And it's not working, I've moved it to the top of the xproj and the bottom, it really just doesn't seem to work. At this point, I find myself having to make a really weird decision about where a folder should be located because of a "project" based IDE interfering with a traditional web workflow, so it seems like something that should be addressed.
It's been a few weeks -- Is there any update on this? I'm using gulp to build and I'm seeing visual studio "go white" when I do a gulp build even with folders excluded.
I've been digging into this. Right now, having a DNX VS project open is causing my output files to get locked intermittently (even though I have them marked as ignored). I've looked into potential causes:
Note that I see this at times in the projet tree: System.AggregateException: One or more errors occurred. ---> Microsoft.VisualStudio.ProjectSystem.Utilities.Designers.ProjectTreeCorruptionException: Failed to update the project tree. ---> System.ArgumentException: An item with the caption "angular-resource.min.js.map" already exists in the tree with the same sort order as the item being added.
@madskristensen , this is getting in the way of pretty straightforward gulp task usage . Is there anything I can do to get VS to "really" ignore folders?
@brphelps I don't think there is but I believe @BillHiebert made some great perf improvements for the RC2 release.
Just our 2cents: on VS 2015 Community Ed..
node_modules
. node_modules
was hidden (automatically?) from solution/project, could only be seen in Solution explorer if we toggled the _Show all files_ button. node_modules
icon was the transparent one with dashed borders. Other folders we excluded explicitly, like typings
and the build output folder (buildOutput
for us) had a regular icon. node_modules
item did not expose any command to hide it from solution, nor to show it. Other hidden folders instead have the command to show them back again in solution.We applied two workarounds at same time, so not sure which one was critical:
node_modules
directory hidden (directory only, not its subtree), .xproj
files in a text editor and manually add node_modules
to the invisible items: <ItemGroup>
<DnxInvisibleFolder Include="buildOutput\" />
<DnxInvisibleFolder Include="typings\" />
<DnxInvisibleFolder Include="node_modules\" />
</ItemGroup>
Now _Find in files_ seems quite speedy, and does not report results found within node_modules
anymore. Strangely enough, it keeps on finding results from typings
and buildOutput
, even if those are hidden from solution and are also flagged as hidden in Windows explorer
+1 - node_modules
on my project contains the selenium c# bindings which are not compatible with .NET Core but VS includes the files in the build causing it to fail. I am running ASP.NET Core RC2 and the preview tooling.
Edit:
This was my mistake / oversight. You can get compile to ignore a folder in RC2 but adding to your project.json within build options:
"compile": {
"exclude": ["node_modules"]
},
More detail in CLI Bug 2841
TFS Bug#231280
Thanks for logging this. I am also running into this for bower components, but bower components are loaded into wwwroot/lib which is not ignored. Some of the bower components have .ts files as well as .tsconfig files which causes tsc.exe to exit with errors for various reasons. I tried to use the above exclude directive in the project.json but it is not working for me.
Thanks
Also need this.
Have project which builds using a temp folder. Visual studio, attempting to update both TFS and read with TSC (Typescript Compiler), white screens attempting to read this folder.
So has there been any update to this? It's literally not possible to create large web applications in Visual Studio using node or bower because of this. It just kills performance to the point where it's not usable...
It's unfortunate but I believe the "open source" movement is taking away resources from Visual Studio (and its loyal users). If there was no Visual Studio Code most of these Visual Studio issues would have been fixed BEFORE release of ASP.NET 5/Core. While I do like the support for JavaScript frameworks and tooling I think the TypeScript support is still much less than perfect. I have several TypeScript files that I added to the ASP.NET Core solution (with the latest VS tooling) and the Visual Studio/TFS integration want's to add/check-in all the JS and Map files by default because they are part of the solution. Who wants that? All I need in TFS is the TypeScript files and maybe some selected straight JS files that I specify. Having the files in the file system drive the solution structure MAY BE an OK idea but is one that did not consider typescript projects (which are growing exponentially). Who wants to write direct JavaScript anymore?
Also, still constantly fighting with debugging TypeScript files because the JS/Map files are cached by IE so I have to clean my solution, delete history in IE, and then debug after every TS file change I make. I hope I am missing something here because it's hard to believe that the developers of the tooling have not run into this problem while testing/debugging a TS solution.
While I'm at it I may as well mention the "TypeScript Virtual Project" which I have no idea what that is or why I need it but it seems to be getting in my way.
This problem makes Visual Studio unusable for large web projects. It literally can't function like this. Please, do something soon.
Hiding files from the Solution Explorer doesn't stop Visual Studio from trying to do things with them. This problem is so bad that I dare say it shouldn't be legal to say Visual Studio can build web projects, anymore. Anything more than adding jquery
and the rudimentary template defaults is completely unusable.
@ciel You hit it right on the button. I started monitoring this thread awhile ago but I finally had to make the obvious decision of not using asp.net core. The built in npm, typescript, etc... functionality just isn't ready for use on projects of size.
@ciel @bjporada It seems we are the victims of hostile takeover from the OSS guys in the name of community. They literally hijacked VS but thankfully haven't ruined it completely because it's still the best tool for legacy projects.
What seems obvious is the apparent lack of experience within the #aspnetcore team of any kind of ISV work. I bet these guys never actually used VS to build web sites/web apps for paying clients.
BTW, the same goes for IIS/Kestrel integration which even today is at rudimentary level.
I think brandishing insults and unfounded accusations isn't likely to get
the team to fix this problem.
I'm not sure what gives you the idea that this has anything to do with OSS.
You sound like a gamer elitist that talks down to girls at conventions
because they aren't "real gamers".
On Sep 6, 2016 2:32 PM, "Marko Hrovatic" [email protected] wrote:
@ciel https://github.com/ciel @bjporada https://github.com/bjporada
It seem we are the victims of hostile takeover from the OSS guys in the
name of community. They literally hijacked VS but thankfully haven't ruined
it completely because it's still the best tool for legacy projects.What seems obvious is the apparent lack of experience within the
aspnetcore team of any kind of ISV work. I bet these guys never actually
used VS to build web sites/web apps for paying clients.
BTW, the same goes for IIS/Kestrel integration which even today is at
rudimentary level.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Tooling/issues/94#issuecomment-245063310, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAavtPHN7IJVZeCT9KyQlur0ZtFm4W1Tks5qnb_RgaJpZM4FAV7x
.
I'm not sure what gives you the idea that this has anything to do with OSS.
Because subpar VS tooling and the general idea that everyone should use VS Code now.
btw I don't understand where you saw insults and unfounded accusations, I think it's an accurate observation otherwise I don't know why would you kill a feature that literally every developer needs a couple of times per day
close VS and cut the folder from work space and paste in another destination, and open VS and delete the folder from VS and close VS and return folder to his place and open VS
This is so frustrating, nothing on this post is yet to work! :(
I cann't believe I'm having such an issue in VS + ASP.NET Core project! Using Ember-cli is a pain, because when you build *.js files, the ember-cli uses "tmp" folder to place there huge amount of files (about 350-500 Mb). Then VS immediately starts to process them and hangs for about 3-5 minutes! That is just crazy.
Please, add the ability to exclude folders and files from VS solution
I agree with enterpub, please make this a high priority fix. It makes my project very, very hard to work with!
The GitHub Issue Tracker for the aspnet/Tooling repo is being deprecated in favor of Visual Studio's Report a Problem tool.
If this issue is still a problem with the RTW release of Visual Studio 2017, please report a new issue using the Report a Problem tool. While you can still use .NET Core and ASP.NET Preview tools with Visual Studio 2015, Visual Studio 2017 is now the officially supported tool for developing .NET Core and ASP.NET Core projects.
By using the Report a Problem tool (available in both VS 2017 and VS 2015), you can collect detailed information about the problem, and send it to Microsoft with just a few button clicks. See Visual Studio's Talk to Us page for more details.
Please use the discussion topic here for feedback and questions on the deprecation of this issue tracker. Thanks!
all:
As requests by the webtools-bot
in the reply before me, I have opened a new issue for this on the VS developer community.
Please direct comments and vote for the problem here: https://developercommunity.visualstudio.com/content/problem/117014/we-need-a-way-to-exclude-a-folder-from-projects.html
Most helpful comment
Hiding files from the Solution Explorer doesn't stop Visual Studio from trying to do things with them. This problem is so bad that I dare say it shouldn't be legal to say Visual Studio can build web projects, anymore. Anything more than adding
jquery
and the rudimentary template defaults is completely unusable.