Develop Reference

Getting Custom ContentType to Register with Auto-Completion in VSIX Extension

I've written an extension to provide IntelliSense auto-completion for an VS Isolated Shell. The issue I'm having is making this auto-completion apply only to files of a particular file type. I've followed the guide here to do so.
Relevant class file:
using Microsoft.VisualStudio.Utilities;
using System.ComponentModel.Composition;
namespace VSIXProject1
{
internal static class FileAndContentTypeDefinitions
{
[Export]
[Name("assembly")]
[BaseDefinition("text")]
internal static ContentTypeDefinition hidingContentTypeDefinition;
[Export]
[FileExtension(".asm")]
[ContentType("assembly")]
internal static FileExtensionToContentTypeDefinition hiddenAVRASMFileExtensionDefinition;
}
}
Despite this, when I put the [ContentType("assembly")] export on the ICompletionSourceProvider and the IVsTextViewCreationListener that are used to handle the IntelliSense integration, the auto-completion fails to show up at all. However when I use [ContentType("text")] or [ContentType("plaintext")] the auto-completion will show up on either all files or just .txt files, respectively.
This is the first VSIX plugin I've tried to make so maybe I've missed something. Currently, I'm at a loss for what to try next. A lot of googling hasn't yielded much information, and the code resources I have found seem to implement this behavior in the same way I'm attempting to.

So after a few unsuccessful attempts, and a stroke of luck, I realized what my issue was. The specific Isolated Shell (Atmel Studio) I was trying to write the extension for already had a ContentType for assembly files. I'm guessing that when I added my own content type it was overwritten by the shell itself.
In order to fix the issue, I used the ContentType name that the shell uses which happened to be "assembler". This happened to be a lucky guess based on the languages that appear under Tools > Options > Text Editor. Hopefully, this helps someone who runs into the same issue in the future.

Visual Studio C# Winform Designer is creating strange code for control members?

Thanks for your time everyone.
I'm working with C# .Net 4.0 and Visual Studio 2010 Professional. I have a few buttons, a richtextbox, and a splitcontainer on the form. There isn't a whole lot of code, and it doesn't really do much at the moment. There are two projects in the solution: call them MyProject and MySupportProject. The form is located in the MyProject project.
Every once and a while when I try to run the program, I get two errors:
'MySupportProject.Properties.Resources' is inaccessible due to its protection level
'MySupportProject.Properties.Resources' does not contain a definition for String1'
So I go look at the designer, and for some reason it keeps filling in the following:
this.rtbStatus.Text = global::MySupportProject.Properties.Resources.String1;
And I have no idea why. I delete it or comment it out and it keeps generating that line. The RTB (RichTextBox) in the form has no text associated with it.
In the solution properties, MySupportProject is listed as a dependency of MyProject, but I can't for the life of me figure out what it is trying to do with this particular RichTextBox with that particular non-visible string. I looked into the resource in MySupportProject a little bit and found the definition:
/// <summary>
/// Looks up a localized string similar to .
/// </summary>
internal static string String1 {
get {
return ResourceManager.GetString("String1", resourceCulture);
}
}
It looks like the above definition was generated by some tool, but I'm really not sure where it came from. Someone worked on this project before me, so they could have put it in, but I started the form from scratch and I'm not making the connection. Has anyone ever had a similar issue? If not, is there something else I should try to stop this annoying occasional build failure? Thanks for all your help!

I don't exactly know reason behind this, but you can just replace the line with this:
this.rtbStatus.Text = "";
or:
this.rtbStatus.Text = null;
Also, try delete that string resource of yours. If you can't then do this:
Check if there are any other resources stored in the resource file.
If yes, then copy all the other resources into a new resource file and delete the old file.
If not, then just delete the old resource file (.resx) and create a new resource file.

When I build a Silverlight project, what happens to XAML files?

Can you please explain the life-cycle of an XAML file in terms of compiling?
When I build a Silverlight project what happens to a XAML file in the build process?

The answer about the intermediate .g.cs file by Jon Skeet (now deleted, but that part quoted below for context) was partly correct but did not answer your actual question in full:
JS: An early part of the build process creates a Foo.i.g.cs file in the
obj directory containing a partial class, and that gets compiled in
the normal way along with your own .cs files.
The .g.cs files contain pieces missing from the code-behind required to connect named elements to class members during InitialiseComponent(). e.g. this is from a basic MainPage.g.cs:
public void InitializeComponent() {
...
System.Windows.Application.LoadComponent(this, new System.Uri("/SilverlightApp1;component/MainPage.xaml", System.UriKind.Relative));
this.LayoutRoot = ((System.Windows.Controls.Grid)(this.FindName("LayoutRoot")));
}
This is bit like the designer files generated for WinForms controls/dialogs, but happens at compile time instead of design time.
The compiler parses to validate the XAML and to determine what named elements need to be generated (into the partial class).
The XAML file itself gets stored as a resource in the DLL during the build (in the example above it is stored as "/SilverlightApp1;component/MainPage.xaml")
Note: For WPF only, the embedded XAML file is actually converted to a more memory-efficient binary version referred to as a BAML file.
Answering your comment to Jon Skeet (now deleted), you are partially correct in asking:
So parsing the whole XAML document -all the elements, attributes etc.-
is not part of the WPF or SL builds? Am I correct?
Aside from the parsing mentioned above, for validation and named elements, the rest of the parsing (of the element tree and templates etc) is actually done at runtime when LoadComponent() effectively deserializes the XAML and creates a visual tree of elements you authored.

When you build a Silverlight project a .xap file is created, this is basically just a .zip-file with another extension, containing an AppManifest.XAML and your project in a DLL-file (together with DLL:s for other dependencies).
If you run the DLL through dotPeek or Reflector you'll see that the XAML-files you created are found intact in the resources of the dll.

How to programmatically control the Build Action of the new files generated from a T4?

The question is: is there a way to have a setting in the *.tt file so that the generated files are set to a specified Build Action?
The thing is I am generating code using a template, but it only meant to be a starting point, eliminating a lot of typing. I do not want anyone to use the code(generated classes) as is, nor I want it to clutter the namespace. Currently, I have to manually set the Build Action to None every time a new file being added by the template - I would like to automate it.
Thank you!

A very simple workaround is to wrap the generated code into an #if statement:
#if GENERATED_CODE
// my generated code
// will compile only if the variable GENERATED_CODE is defined
#endif

How to Stop VS Designer from messing up my already present code

Everytime I move to Designer View my whole designer.cs code is messed up :
VS Designer reorganizes code blocks and puts an irritant verbose prefixes like "this.whatever"
and fully qualifies objects using "System.Windows.Forms.whatever"
I Know that "Designer.cs" is not intended to be edited but I need to do some GUI code customization from time to time and would like these to stay as I changed them.
How to avoid that ? (Guess this is too funky for VS to handle)
(Actually I am just avoiding the use of the designer and do it all by hand, the good old way)
Update : I am surprised to see the herd-like reaction towards this question. Sorry if it is disturbing, but it is interesting to see that, before hitting me on the hand saying "DON'T DO that, it's Bad", NO ONE asked WHY I wanted to do it. IMHO the question is relevant and that's why : Many of the "auto-generated" code is rubbish and of absolutely no use, it does need some enhancement. One example (among soooo many others) : Why generate a Size/Location property when the control's Dock Mode is set to Fill ? I wanted to take advantage of the benefits whithout the drawdowns. Anyway, I'll keep the short answer : You take it ALL (with the rubbish) or leave it ALL.

It's simple: don't edit the designer code. Those warnings are there for a reason, and for Visual Studio to work correctly it needs to own that file.
This is a partial class: everything you need to do, you can do in the matching non-designer file for that class; this includes all your control declarations and other things. Since you're trying to avoid the designer entirely, let visual studio have that file and just put everything in your normal .cs file.
Update:
Based on the comment, I want to add the following —
Either use the designer or don't use the designer. Don't be wishy-washy about it. If you're using and relying on the designer for some things, you MUST leave the designer's file alone.
If you're avoiding the designer, then really avoid the designer. Everything it does you can do in your own code (except of course for the visual queues, but even that can be done better via prototyping). You can even create your own additional file for the partial class to keep designer-like code in.
If you're only using the designer as an occasional code generator to help reduce some boring typing, do that in a separate project or on a throw-away form in your existing project and just copy/paste the code over.

The designer should only be writing code in FormName.Designer.cs which you should not touch. Visual Stuiod declares a partial class implemented in two files - one for the designer, and one for your code. I'd be surprised to hear that the designer was rewriting the non-designer file.
If this doesn't help. please give more details of which version of VS you're using, which files are being rewritten, and which bits of those files.

You can always extend the designer class by putting your custom code in another cs file. The designer can't touch that and the compiler will compile your additions to that class. If you're doing something like adding properties or methods its super to simple to do:
// MyWinformExtension.cs
partial class MyWinformName
{
public string Foo { get; set; }
public void ProcessData()
{
// do some processing..
}
}
Voila! That's how you add your own code. You can't alter the designer code because it will be re-written ALL DAY LONG by the IDE. That's why there are warnings in the source and why everyone else is telling you the same thing.