Submit My Question - Recent Questions - Recent Answer

The IDE often automatically changes the file subtype from "Form" to "Code" i

The IDE often automatically changes the file subtype from "Form" to "Code" in the .csproj file, which renders the forms unviewable in design view until that change is undone. Is there any way to prevent the IDE from doing this automatically?

Thanks,
Wilfred

[276 byte] By [WilfredTang] at [2008-3-6]

«« SQL Server and Access
»» ClickOnce and MSBuild

# 1

This sounds like a bug. If you can reproduce it consistantly, post a bug report on the Microsoft Product Feedback Center.

DavidM.Kean at 2007-9-9 >

top of Msdn Tech,Visual C#,Visual C# IDE...

# 2

What kind of change is that? Say, for example, if the Form class isn't the first class in the .cs file, the IDE decides that it cannot be designed and changes the subtype to "Code"

VijayeRaji at 2007-9-9 >

# 3

Wilfred,

In what situations are you seeing this change occur? We know of one issue that would cause the DesignerCategoryAttribute not to function properly when applied to a Form, but we haven't seen one that would cause it to flip back and forth without this. Are you talking about VS 2005, or VS 2003?

Thanks,
Anson Horton [ansonh@microsoft.com]
Visual C# IDE PM

AnsonHorton at 2007-9-9 >

# 4

Hi Anson,

I see this consistently in VS2K3. Typically C# files with a large compiled binary 100K+ containing forms that reference base forms in a different dll. The forms are referenced by project, not by binary. Projects are set to "copy local".

Initially the problem only appeared in the inherited library, but now it is starting in the base library too. I think it may be related to the 128K mark?

All my items in that file are changed to subtype code - components, user controls and forms. I have to exclude and re-include all files to get a fix.

Deleting the obj, bin, suo and .user files has no effect.

Thanks,
B.

BrianRogers at 2007-9-9 >

# 5

We just started having this problem with all our windows projects -- the IDE keeps changing the "subtype" of each file from form to code. We have a large solution with many base forms in separate dlls (as you describe above -- I don't know if this relates to the problem, though). We just switched source control and did not have this problem before. Previously we were using SourceSafe binding in our IDE and this problem did not happen -- I think it was just because the IDE would not automatically mess with the readonly project files. We recently switched to AccuRev and are not using binding for our project so the project files are now all regular writable files. Now this problem happens almost every time the solution is opened -- most of the windows project files get messed up. We are using visual studio .net 2003. Even if there aren't serious consequences for the types changing, this problem is making it difficult to work with source control as many project files are being changed spuriously and it is difficult to recognize what changes are real.

BobAbraham at 2007-9-9 >

# 6

Brian,

Unfortunately I haven't heard of the problem before. We did have a bug in 2003 that, with large solutions, it was possible for the cache of IntelliSense information to become corrupted. This would cause the behavior that you're seeing. That cache was stored in a file called <projectname>.projdata and it's a hidden file. It is stored in your project directory under obj\<configname>. Since you're deleting all of those directories and still having the problem, it must be something different.

It would be pretty difficult to debug over the forums :), so the nex step is to contact Product Services and Support. They should be able to help nail down a repro and get you an answer on how to work around (or fix) the problem.

Sorry I can't be more help!

Anson Horton [ansonh@microsoft.com]
Visual C# IDE PM

AnsonHorton at 2007-9-9 >

# 7

Hi Anson,

I remember the bug when dll's got over 64K that the intellisense would fail or lock a dll. The problem I am describing is the same one everybody else in this thread is experiencing. Seems it is not just restricted to me.

Thanks,
B.

BrianRogers at 2007-9-9 >

# 8

Has Microsoft identified/addressed the problem described in the original post? I'm also seeing a consistent change from FORM file types to CODE w/o my direct involvement (i.e. the IDE changes it for me, at its whim).

This is turning into a real problem for our development team as it is getting to be very tedious to have to (manually) change/fix the issue each time the IDE decides to change the file subtype on our behalf.

I don't have a problem spending (my) time figuring out how to reproduce it, but I'm not going to be happy one bit if MS comes back and says "that is a known problem and will be fixed in a subesequent release of VisualStudio"...

Could someone from MS please research this issue (i.e. take a look at the source code) and determine what reason(s) the IDE changes a subtype from FORM to CODE.

BretPehrson at 2007-9-9 >

# 9

This has been an ongoing frustration for our team. We have seen this in a lot of scenarios and there doesn't seem to be any rhyme or reason to it.
One scenario where I see this fairly consistently is after switching to a different development branch in source control (switch in Subversion). When I open VS2003 with the new solution, many of my project files exhibit this problem. The files show changed in Subversion, so usually it simply a matter of closing VS, reverting those files, and reopening VS. Strangely enough, it doesn't seem to happen after the second open.

bvanderw at 2007-9-9 >

# 10

I have been working outside of a file control system (actually a disconnected non-integrated source control system) and I still have these issues. The problem became more frequent when I moved my base form into a different dll from the application and other dlls.

I think the reason you get the problem when switching branches is that the contents of project files and intellisense is re-processed after recompiling the project. Once you have fixed the files (I find), they remain fixed until you change again (causing all the meta-data to be incorrectly regenerated).

It is a constant problem and causes me hours of labour. My quickest solution so far is to open the solution and replace the base form name with itself throught the solution. This seems to cause all the forms to correct themselves.

Seems MS has no iterest in addressing or resolving this issue to date. Unfortunately I do not have code I am allowed to send them although the problem is truely reproducable.

BrianRogers at 2007-9-9 >

# 11

Yes, this is really irritating and we regularly spend hours fixing the consequences Sad

AndrewSkalkin at 2007-9-9 >

# 12

I think this has to do to with reference dll and inheritence. Seem to me like you store dlls on your source control. After you check out the whole solution from source control which contain dlls. IDE will validate those source code dependency in project file with those dlls. If you make a change to those project that has dll on source control but never check in the new dll. That will cause you a problem.

Hope this help.

Cha Chunchadatharn

ChaChunchadatharn at 2007-9-9 >

# 13

I still get the issue when I am not using source control.

BrianRogers at 2007-9-9 >

# 14

look at this url

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=f39a46fc-5dac-4a55-81ef-e1d262fe0040

ManagedSnake at 2007-9-9 >