I suggest you ...

Improve link-based projects UI and UX

I want to be able to configure a C# project so it recursively links code files and asset files that reside in another folder, being able to better organize my project architecture and share everything that can be shared between different projects, without having to create code libraries and such.

What is implemented:
- You can manually link files in the Add\Existent Item wizard. Having a programmer do manual and repetitive tasks? Madness? No, this is SP... You get the point.
- Edit the .csproj file and insert something like this, that will recursively link .cs files and folder structure, while excluding some junk:
<Compile Include="..\BaseProject\**\*.cs" Exclude="..\BaseProject \bin\**;..\BaseProject \obj\**">
<Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
</Compile>

What's the problem then?
- Visual Studio 2013 isn't currently automatically refreshing updates, for instance, if you add a new file on the base folder, it will only be linked in the project if you unload/reload the project. You won't be able to compile that file if it isn't showing up in Solution Explorer.
- For each file you add or remove, there will always be some repetitive time consuming task that shouldn't be in the first place.
- As stated in MSDN, the Solution Explorer Refresh button will not refresh link-based projects.

My solution:
- Add UI to configure file linking. Being able to link folders and sub folders, filtering files and excluding files and folders. Basically, some UI to add the above code does.
- Implement file watcher for linked folders AND/OR at least a button to refresh links.

51 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Álison Fernandes shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for taking the time to share this suggestion. This item has been around for a couple of versions of Visual Studio and we haven’t acted on it. Looking at the VS “15” plans, we’re not going to take action on this item, so we’re going to close it. If the suggestion is still relevant, please either take a look to see if there’s another suggestion that’s similar that you can vote on, or open a new suggestion.
- The Visual Studio Team

2 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Serge Populov commented  ·   ·  Flag as inappropriate

    Forgot to say why using junction folders as workaround is awful. A couple of examples:
    1. It doesn't play well with source control systems (git, svn, etc.) and their VS plugins - they don't display status, changelog, etc. for files in junction folders, and can't handle creation of new files properly.
    2. Sometimes there VS locks those junction folders, so it's impossible to modify them until VS is closed. The most sad, that VS can lock handle for not-yet-created junction folder, that was added in commited version of project and should be created on next build.

  • Serge Populov commented  ·   ·  Flag as inappropriate

    Absolutely agree. Now I work in second company (and, I guess, "It's over 9000!" of them), that use some hand-made shell scripts for creating junction folders in such cases, that run as pre-build commands, but it still doesn't solve the problem entirely, as we still need include files in project manually. And that's awful.

Feedback and Knowledge Base