search

dotnet / project-system

The .NET Project System for Visual Studio
MIT License
969 stars 387 forks source link

SubType Designer is randomly added in csproj files #3186

Closed rainersigwald closed 6 years ago

rainersigwald commented 6 years ago

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: Microsoft/msbuild#2876

rainersigwald commented 6 years ago

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 commented 6 years ago

From @KirillOsenkov on January 25, 2018 4:56

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

rainersigwald commented 6 years ago

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 commented 6 years ago

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

davkean commented 6 years ago

@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 https://github.com/dotnet/project-system/issues/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 commented 6 years ago

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 commented 6 years ago

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 - #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 commented 6 years ago

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

davkean commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

Internal bug number for the connect issue is 658114.

davkean commented 6 years ago

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 commented 6 years ago

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

davkean commented 6 years ago

Thanks, I've routed to the correct team.

KirillOsenkov commented 6 years ago

:+1:

StingyJack commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

Can it also be fixed in VS2017?

davkean commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

smithkl42 commented 5 years ago

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 commented 3 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 11 months ago

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.

yuriiproniuk commented 1 month ago

I landed on this thread with label 'Closed' happily expecting to find the solution just to find out that issue is still unresolved. Why closing issues that are not resolved?

SoulSeekkor commented 1 month ago

That is a great question, unfortunately that happens with many of the VIsual Studio issues that have been around for years now.... Both on here and the Visual Studio support forums.

julealgon commented 1 month ago

@davkean can't you leave this open until the underlying problem is fixed? You are just creating confusion in the community with your current process.

KirillOsenkov commented 1 month ago

@drewnoakes

drewnoakes commented 1 month ago

To anyone who is still hitting this, please file a new ticket on developer community, providing repro steps (and ideally a recording of the bug happening if possible).

The bug is not related to the code in this repository, so we can't track it here. If you share a link to the ticket here, I'll make sure it's routed to the correct team. Thanks.

rainersigwald commented 1 month ago

No need for a new ticket unless your symptoms are very different from https://developercommunity.visualstudio.com/t/Visual-Studio-keeps-modifying-project-fi/10694196; please upvote or provide more context there.

drewnoakes commented 1 month ago

I suggested a new ticket because that one does not have enough information to be actionable, and adding a recording to a new ticket is easiest. If someone has clear repro steps, then maybe a comment on that PR would be adequate, but a recording of the issue happening would be helpful in the case that the repro steps don't work for whoever ends up looking at the issue.