SubType Designer is randomly added in csproj files

[rainersigwald]

From @EnCey on January 18, 2018 15:31

Steps to reproduce

Edit a csproj file and save it. A Subtype tag with Designer as content is randomly added.

<ItemGroup>
    <None Include="App.config">
        <SubType>Designer</SubType>
    </None>
    <None Include="packages.config">
        <SubType>Designer</SubType>
    </None>
</ItemGroup>

Here is a Microsoft Connect issue that describes this exact problem.

Here is a nearly a decade old StackOverflow question that describes this problem. According to an answer there, this issue has been present since Visual Studio 2008.

Copied from original issue: dotnet/msbuild#2876

[rainersigwald]

From @KirillOsenkov on January 25, 2018 4:55

I wonder if it's MSBuild or it should go to https://github.com/dotnet/project-system.

cc @Pilchie

[rainersigwald]

From @KirillOsenkov on January 25, 2018 4:56

P.S. Let's fix this, this has annoyed me for years.

[rainersigwald]

The only place I can see where we'd add this is in the pre-MSBuild-to-msbuild converter code, which should never be called:

https://github.com/Microsoft/msbuild/blob/419c6d8e55c9c8181da2ce8d0ef6f951fdfe08a3/src/Deprecated/Conversion/ProjectFileConverter.cs#L576-L578

I think this is a project system bug.

[Pilchie]

Hmm - I know how this process works for Compile items, but not for .config files.

[davkean]

@EnCey Can you expand on the repro steps? Which project type in particular? Can you provide the project, or record the steps that you take to reproduce this?

In .NET Framework based projects, the sub type is added for anything "designable" (Forms, Pages, Components, etc). This is being tracked by #182. You should not hit for app.config or packages.config, that looks like a bug.

In the new project system, we do not currently add sub type unless an external component asks for it. The repro steps will help me understand what you are hitting here. Just reply to the thread with more information and I'll reopen it. Thanks!

[EnCey]

Sorry @davkean for not providing more steps. I encountered the issue while I was upgrading all projects of a solution to .NET v4.6.2 (from 4.6).
During my investigation I found the already mentioned StackOverflow question, in which people report this problem since Visual Studio 2008 (and still present in VS 2017). I thus thought that it would be a known issue, especially considering there's also a Microsoft Connect issue for it, which is sadly unreachable now.

In the SO question there's a link to this MSDN forum question in which people report the issue for all kinds of project files. In my case, the sub type was definitely added to .config files as my example shows.

I do not have a working repro and don't remember in which project exactly the issue occurred, but isn't a decade of reports evidence enough for your Q&A team to at least look into this? Perhaps the existing reports already contain enough information for you to identify the root cause.

When I run into the problem again I will post steps here, but for now I'm afraid I can't provide more details.

[davkean]

I've pulled the connect repro steps because Connect has been retired:

Repro Steps: 
1. Open attached project 
2. Go to solution explorer 
3. Double click on XML file 
4. Close solution. 
5. Nothing changes. 
6. Open attached project 
7. Go to solution explorer 
8. Right-click on XML file and select "View code" 
9. Close solution 
10. You're prompted to save changes to the project file 
11. Save the changes 
12. Project file now has needless SubType Designer decoration 

Actual Results: 
If no designer functionality is available, my project file isn't modified. 

Expected Results: 
My project is modified, causing needless version control churn.

Looking through all of the links you posted, there's 2, possibly 3 separate issues:

1. Project system is adding SubType to designable files. This behavior is as designed - Prevent <SubType> from being written to the project file #182 is tracking revisiting that design. (MSDN Forums)
2. Something is adding SubType to XML files in some cases in VC++ projects (Connect/Stackoverflow question)
3. Something is adding SubType to config/XML files in some cases in legacy C# project system (your issue)

I'm going to use this bug to track the last two and find an owner. I'll dig through some code to see if/when this occurs. I suspect this is XML editor component and not the project system.

[davkean]

Could you double-click those two config files and tell me what editor opens?

[davkean]

Okay, I can see where this code lives, Package.CheckItemSubType in the XML language service (internal). Looks like both 2 & 3 above are caused by the same thing. Trying to understand the logic, and why it happens.

[davkean]

@EnCey Can I ask you a favor? Can you Help -> Send Feedback -> Report a Problem and report the same information. Once you've done that point me to it and I'll make sure it gets routed to the right team. I'll add background information to the bug about what I've found, it appears the Connect bug fell off the radar. This is a issue in the XML editor - it looks intentional that its doing this but I'm not entirely sure why.

[davkean]

Internal bug number for the connect issue is 658114.

[davkean]

I've filed https://devdiv.visualstudio.com/DevDiv/_workitems/edit/572846 internally. If/when you Send Feedback above, I'll associate that bug with it. Community based feedback lets other people vote on the issue and is given weight over just internal filed bugs.

[EnCey]

Hi @davkean , thank you for looking into this!
I reported the problem like you asked here

[davkean]

Thanks, I've routed to the correct team.

[KirillOsenkov]

👍

[StingyJack]

Sorry, what's the result of this? Its kind of annoying and a minor timesink to keep coming up in pending changes or code reviews.

[EnCey]

@StingyJack and others annoyed by this bug: please head over to the Developer Community issue and upvote it. Leave a comment / reply if you want to generate even more buzz.

As davkean mentioned above:

Community based feedback lets other people vote on the issue and is given weight over just internal filed bugs.

My personal impression of the situation is that this issue now sits in some "fix when time" backlog (aka never ;), so we'll need some noise to generate interest.

[StingyJack]

Sorry again, but devcomm is a no-go for me anymore. Less than 25% of about 230 issues i opened were resolved, and after pointing out the weird or atrocious mishandling for a few issues, it was apparently easier to suspend my accounts with a suspect excuse rather than address the mishandling problems and the unresolved issues.

EDIT: So I'd probably cast a vote for your issue, but I cant, and really shouldn't have to. If we are taking the time to log a bug for something that is interfering with our work, we shouldn't have to campaign for votes to get things fixed. I could understand if this were solely a free or community version of the program, but those who have paid for a license (pro, enterprise) are not getting any improved level of service for it.

[davkean]

@StingyJack If there are bugs or issues that are blocking your work that you would like to see addressed, please open a support request. Github/Developer community are intended as convenient ways to report issues and bugs to Microsoft and not intended to replace existing support mechanisms.

[StingyJack]

Sorry a third time (and final I promise) for belaboring this thread. @davkean - Is there an email address I can reach account support at? One of the unresolved issues on devcomm is that my accounts aren't linked right.

[davkean]

Just to follow up on the thread around the original issue; this bug has been addressed and will appear in the first preview of VS 2019.

[RealDotNetDave]

Can it also be fixed in VS2017?

[davkean]

@RealDotNetDave There are no intentions to back port this fix to Visual Studio 2017. Given VS 2019 RC has been released it's moved to a servicing level where only bugs blocking major scenarios are being addressed. VS 2019 RC has a go-live license, so you can use it for production code.

[smithkl42]

Given that this is fixed in VS2019, highly ironic that I just ran into this in VS2019 :-).

I upgraded to 16.0.1 today, and when I add new classes, it insists on treating them as components, i.e.:

    <Compile Include="Validation\Commercial\CommercialDataValidatorBase.cs">
      <SubType>Component</SubType>
    </Compile>

[Pilchie]

@smithkl42 The issue was fixed for xml files (hence the original report). For .cs files, the language service checks the first type in the file and all of it's base types to see if any of them have the DesignerCategoryAttribute applied. If one does, that category gets written to the csproj file as the SubType. It sounds like that's what is happening in your case. If you want to override that, add a DesignerCategoryAttribute with a value of code.

[Pilchie]

See http://source.roslyn.io/#Microsoft.CodeAnalysis.Features/DesignerAttributes/AbstractDesignerAttributeService.cs,ff002caa978ececb for where this happens.

[smithkl42]

Thanks, that explains it. We have our own ServiceBase class, but I accidentally had my class inheriting from System.ServiceProcess.ServiceBase. I'm guessing that or one of its basetypes must have the DesignerCategoryAttribute applied.

Sure had me scratching my head...

[michaelkhalsa]

I had this problem in Visual Studio 16.11.1 when closing Visual Studio randomly removed the SubTypes (Form, User Control) for about 90 % of thousands of user controls and forms in vbproj (winforms, targeting NET 4.8, vb for winforms project, mixed vb and c# for other projects in solution).

Unable to replicate. I had previously renamed some user controls prior to saving.
Note that my solution (a large application) frequently runs out of memory every 2 or 3 days. (I have already split projects into a few solutions), however, has not had memory issues in these later VS builds.

Fixed it by pulling a previous vbproj file saved in git, and then hand modifying changes since last push.

So this issue is still kicking.

[ajmudrak]

I noticed this issue in one of my projects, and found that in one build configuration (production) we would run the build and it would remove the SubType, but other build configs (dev/test) it would add it back. It turns out that the code behind file (.aspx.cs) was entirely inside a preprocessor directive that hid all the code for the production build config. When we removed that directive (we did not actually need it to fully remove the code behind) it stopped removing the SubType and the builds became consistent. Just food for thought.

[oaspublic]

the problem still exists with a current visual studio. regularly after a git branch change the project files are modified with extensions or deletions of subtypes. so when changing from branch a to b the subtype is inserted and then with a future identical change from branch a to b the subtype is removed again. the behavior is very disturbing and irritating, because sometimes an automatism arises and with essential changes in prj files, sometimes accidentally wanted changes are retooled!

[SoulSeekkor]

I've never had this issue until recently (maybe the last 6 months) and it's happening in VS 2022. Super super frustrating as I'll save my solution and it'll randomly add this subtype garbage to a VB.Net project file that I didn't even touch at all or have open.