Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Description of Problem:
Creating a code file without the ".cs" extension will break the C# 'partial' keyword for that file, permanently. Renaming the file to fix the extension problem does not fix the 'partial' keyword being broken.
Steps to reproduce the problem:
1. Create a new C# class file. (ex: "FirstPart.cs")
2. Add the 'partial' keyword to the class. (ex: "public partial class FirstPart")
3. Create another C# class file without .cs extension (ex: "FirstPart.SecondPart").
4. Realize your obvious mistake, and rename the file to the proper extension (ex: "FirstPart.SecondPart.cs").
5. Close the tab for the second class file and re-open it to regain proper syntax highlighting.
6. Add the 'partial' keyword to the second class file. (ex: "public partial class FirstPart").
7. Add a method to the second class file (ex: void YouCantCallMe() ).
8. Add a call to invoke the method from the first class file (in the constructor is easiest).
9. Try to compile the application in futility.
The compiler will complain (CS0103) that the method does not exist in the current context.
The compiler should have no problem finding the method in the properly defined partial class set.
How often does this happen?
Every single time you make a class file without the .cs extension and then rename it and try to use it as part of a partial class.
If you create the files with proper extensions, there is no problem. Using my examples, creating "FirstPart.cs" and "FirstPart.Second" will cause the bug to appear. Renaming the file to "FirstPart.Second.cs" will not fix the file. However, if you delete "FirstPart.Second" and re-create it as "FirstPart.Second.cs", all is well.
In reality, this happens more often than you might think due to the reliance on default extensions. I can create class "Foo" and it will be "Foo.cs". However, being lazy and creating "Foo.Bar" will make literally just that, and not "Foo.Bar.cs".
Please Attach a solution that exhibits the problem. I suspect your namespaces are wrong.
Created attachment 3485 [details]
Solution with Bugged Partial Class
Created attachment 3486 [details]
Solution with both Bugged and Working examples (identical code)
The solution has two projects, one broken and one working. There is no difference in the code between the two, just the difference of creating the file, renaming it and just creating it right the first time.
It's a bit weird - right. But in fact it's a feature:
If you add a file with an unknown extension the compile action is set to 'None' - this makes sense otherwise you get compile errors.
Now if you rename that file the compile actions don't change by default. If you do this you need to set the compile action to 'Compile' - then it'll work.
Many IDEs will change the compile action based on the new file extension, so migrating users may have that expectation.
The problem with the current feature is that it can easily create some head-scratching moments, like in the example I had attached.
Here are some options to consider:
1. Automatically change compile actions based on new file extension.
2. Ensure that new C# code files are created with the .cs extension, supporting multi-dotted file names (ex: "FirstPart.Second" should create "FirstPart.Second.cs").
3. When renaming to a code extension (like ".cs") bring a dialog to the user asking them if they would like to change the compile action.
4. Add a new user preference such as "Change Compile Action on Rename: (Never | Ask | Always)" to deal with options #1 and #3.
With C#'s partial class naming conventions (Main.Sub.cs), it can make it rather easy to do this when lazily inputing the file name without the .cs extension in the dialog. For this I highly suggest option #2.
Ok I can't find any reason why it is like we did it.
I think it makes no sense, reopening.
I have checked the issue with following builds:
X.S 4.2.3(build 24)
Now I have checked that:
1. When changing the extension of file, Build action gets changed
2. I can use multi dotted in file name.
3. When renaming the code extension I am not seeing the dialog.
Please let me know are these features which are implemented ?
Check the build action of the file - that's changing. There is no need for an obstrusive dialog.
Build action getting change when changing extension of file.
Changing status of this issue to Verified.