We Keep Coding

How to setup solution for 32-bit winform that references 64-bit class library?

I have two projects in a solution:
MyWinForm - a 32-bit project with custom user controls
MyClassLibrary - a 64-bit project that requires 64-bit for math operations
I am "forced" by microsoft to generate user controls that are 32-bit assemblies. See here for reference
I am "forced" by my math model to require 64-bit math operations.
If I reference MyClassLibrarywithin MyWinFormand maintain it as a 64-bit assembly, then my math operations complete with success; however, I can no longer use a custom user control. I get the following error if I try: "failed to load toolbox item it will be removed" when I attempt to drag and drop my custom user control to a designer surface.
If I reference MyClassLibrarywithin MyWinFormand maintain it as a 32-bit assembly, then my math operations fail with a OutOfMemory exception (due to 32-bit max size limitation).
How can I setup my solution to allow both a custom user control AND a 64-bit class library to be referenced, avoiding the issues?
I'd really like to be able to use the toolbox and design surface. I have a hunch that I'm going to need to load the custom user control at run-time, so that the dynamic compiler knows how to decided 32 or 64 bit. This defeats the purpose of using a Visual IDE in my opinion.

The solution is a workaround. I realized that my goal is to use the Visual Designer, which runs in 32-bit, so that I didn't have to write any of my own code. Here is what I did:
set WinForms project to be 32-bit.
Created a custom user control.
Build project in 32-bit.
Drag and drop custom user control on to design surface.
Specify all properties of custom user control. (color, size, dock, etc.)
Declare a Form_OnLoad() method.
Copy/paste all auto-generated code from the designer code-behind that related to my custom user control in to Form_OnLoad().
Delete all design elements from design surface related to custom user control. This will remove auto-generated code in the designer code-behind for the custom user control.
Build and test: do I see the custom user control? yes..proceed.
Switch the build settings back to 64-bit for the WinForms project.
Build and test: do I see the custom user control? yes..execute math function...does it work without any exceptions? yes..proceed
This quick and dirty workaround is not ideal - but was very fast to implement. Switching my project to be 32-bit temporarily to active the Visual IDE is "no big deal" for this project.
**** EDIT TO SOLUTION ****
Do not do the above. Instead see Hans comment below.
Admins: sorry for the sloppy Post, feel free to delete this as I don't know if this question and answer will help anyone else but me.

How to create a VS 2008 Windows Forms project programmatically, that can be maintained just like any other project created manually

I have a bunch of control properties (type of control, location, size, etc.) derived as a text file from an old system on a different platform. I thought it would be fairly easy to load these "control descriptions" into a Windows Forms project in VS 2008 and then be able to maintain the new project in VS just as if it had been created manually.
I'm familiar with using VS and C# but it I'm not sure where to start with this.
I searched the web and found a number of articles about creating controls on forms at run time and that is not so hard, given the information I have, but I want the created form to be a permanent part of a Win Forms project, so I need to get what was created at run time into VS, and accessible in the project just as if it had been manually dropped on the designer surface. Is there a way I could create these forms with a program and then "save" them in a form acceptable to VS?
I manually created a windows Form project to try and use as a "template" and identify how VS does it. I have tried to understand the contents and the relationships between the various resource files, but it is a bit too much. There are also warnings that various files are created by VS and should not be amended manually.
I have almost 1000 forms from the old system so the thought of manually having to add each one to VS is pretty non-viable. I could translate the text descriptions into XML if there is a way to feed an XML description of a Form into a VS Forms project...?
Any advice\direction towards this would be greatly appreciated.

VS uses code generation to create controls in Windows Forms. If you look at a form e.g. Form1 that's in your project, it consists of three files, Form1.cs, Form1.designer.cs and Form1.resx. The Form1.designer.cs file contains the construction of the controls in the InitializeComponent method. VS executes this and parses it at design time to give you the design view of the form where you can make modifications. You could write a program to parse your text files and generate C# code for InitializeComponent to get the right effect. There are various options but you probably would want to use the CSharpCodeProvider class.
Another option is to use WPF. Forms are designed in WPF using XAML, which is an XML based format. (By that I mean, an XAML document is also a valid XML document, but the reverse is not true.) If you create a WPF project and add some controls to it then you could take a look at the XAML file to get an idea of the structure.

Use WPF component from external .exe

Here's the situation:
We have an existing .NET executable that contains an application using WPF components (dialogs and forms). This executable was created using Gupta Team Developer 6.1, but I'm not sure that is relevant to my question. We'd like to re-use some of these forms in a C#-application, but this is proving difficult.
When we include the external components, either in XAML or by instantiating them in code, they look OK (i.e. fields, buttons, layout etc.), but the event wiring seems to be missing. Nothing happens when pressing buttons and tables/grids are empty.
I've read previous articles on this site on using external WPF components, but they all mention external assemblies compiled as control libraries. Are we trying to do something that's not really possible?
P.S As an experiment we've tried to instantiate the App-object from the executable directly and this brings up a fully functional version of the entire application (well, duh), but we'd really like to be able to pick and choose from the individual forms/dialogs.

Add custom editor windows to Visual Studio window panes

My Problem
I'm trying to build an extension to Visual Studio that allows code to be edited on a per-function basis, rather than a per-file basis. I'm basically attempting to display code in a similar fashion to Microsoft Debugger Canvas.
I'm wondering how to host multiple Visual Studio editors within a single window (I believe the windows are implementing IVsWindowFrame). The functionality I'm after can be seen below:
Each editor window retains typical functionality and interacts with third-party extensions as expected. (For example, VsVim functions correctly within these windows).
What I've Tried
I've spent almost two weeks researching and trying this stuff and I'm having a lot of trouble figuring out which services, interfaces and classes I'm going to be using.
Reading through MSDN
First off, most of the documentation discusses how to edit a single editor window and add adornments, tags, margins etc. It doesn't discuss the possibility of spawning multiple editors within a window pane.
I've looked through the documentation on a vast number of interfaces of interest to me including IVsTextBuffer, IVsTextView and IVsInvisibleEditor. Unfortunately I can't get some of these interfaces to play nicely together.
On top this, the usually excellent MSDN is extremely lacking in this area. Many of the interfaces contain only a list of members without even a basic remark on intended use and functional. (IComponentModel, for example).
Many of the interfaces make reference to a set of Editor Samples but the code cannot be read or downloaded on MSDN. Apparently it shipped with Visual Studio 2005, but I don't have this version of Visual Studio, nor can I find it.
Interacting with IVsUIShell
I can get access to all WindowFrames open using IVsUIShell.GetDocumentWindowEnum();
I see there is an IVsUiShell.CreateDocumentWindow() method, but I'm completely unfamiliar with the parameters it accepts, or if this is the correct path to go down.
What I need to do
Programatically create a dockable window pane
Programatically add editors to this window pane. (And ensure they're correctly registered within Visual Studio, the running document table, etc.)
Edit:
I'm sorry, I should have expanded on my steps. When I said I needed to register with the running document table and Visual Studio, it's because I want to actually edit the original document in my custom editor. Below is a short example of the functionality available in Debugger Canvas that I'm trying to recreate:
http://i.imgur.com/aYm8A5E.gif (I can't embed a .gif)
Alternatively:
If anyone knows where I can find the editor samples included with Visual Studio 2005 such as the Basic Editor Sample I'm sure I could figure this stuff out. The MSDN documentation has no code samples regarding these interfaces, which has made my job extremely difficult.

The Git Source Control Provider is an open source extension includes a tool pane that embeds a standard editor as a control within a custom WPF tool window. I would use this code as a reference for any Visual Studio 2010+ extension where I wanted to host an editor window in some custom location.
PendingChangesView.xaml includes a ContentControl named DiffEditor, the content of which will be the editor.
PendingChangesView.xaml.cs includes a method ShowFile, which calls a method to create the editor control and assigns the result as the content of DiffEditor.
ToolWindowWithEditor.cs includes a method SetDisplayedFile which returns a Tuple<Control, IVsTextView> interface, which provides access to a Control that can be added to a ContentControl as well as the IVsTextView for the text view. The heavy lifting is in this method.
Note that the SetDisplayedFile method includes several lines with the following form:
textViewHost.TextView.Options.SetOptionValue({name}, {value});
These lines perform key functionality for the Git Source Control Provider such as removing margins and making the window read only. There are many options available, so you'll want to review the documentation for DefaultTextViewOptions and DefaultTextViewHostOptions to apply the ones appropriate for your particular extension.

I haven't actually looked at the files that #280Z28 (why this username?) posted. I used to work on the Visual Studio editor and what you are trying to do has multiple facets to it that you should tackle independently:
Hosting multiple command targets inside a single IVsWindowFrame (this means that you'll have different elements inside the same pane from the point of view of Visual Studio's shell, and each of them need to have their own command handling. Consider the case where you put your caret in one of the mini-editors and want to undo using Ctrl+Z, moments later, you then place your caret into another mini-editor and do the same. Even though the WPF and Win32 focus have remained inside the same window frame (from the point of view of the Visual Studio Shell), the commands need to be routed to different components.
Using editor's that are displaying parts of another document. The mechanisms here that will be your friend are in the projection namespace. Projection essentially allows you to project a piece of buffer (or buffers) into a view. Ellision buffers are special case projection buffers that project from one source buffer into a target view while hiding areas of the buffer (this is most likely what you want). An example of a projection buffer is what happens inside a cshtml file. In that case, there is one buffer containing all the C# code, one buffer containing all the javascript, and one buffer containing the html and each compiler works off of that buffer, but the end user sees a projection of all these buffers into the editor's view with only relevant parts displayed (for example C# import statements are elided even though they exist in the real C# buffer.)
Managing the running document so that when an edit is made in a mini-editor, the real document is dirtied. You need to handle cases where the parent file is already open in the RDT in which case you want to dirty the same document when changes are made, and also cases where the document is not open, in which case you need to create a new entry in the RDT.
Also, please post to the Visual Studio forums, there are people who regularly check the forums and route the questions to corresponding devs.
Generally speaking, when it comes to the editor, avoid any traditional interfaces (anything that does not use MEF), so samples from Visual Studio 2005 should not be used as a reference point.
If you care enough and are in Seattle, you can try to go to campus as an MVP. There are days where you come to campus, and members of varying team will grab a laptop and come to your conference room and you can debug code together or hack away (while having access to debugging symbols and what not).
Last but not least, contact the code canvas guys, I'm sure they've solved many of the problems you are facing.

You need to register a tool window with your package extension; this can be done via the ProvideToolWindow attribute. The following article contains all the required information on how an editor can be hosted in a tool window: http://bit.ly/9VWxPR
Take a look at the WpfTextViewHost class; the article explains that this type is actually an UIElement, so I imagine that it´s possible to host multiple instances of it...

Adding items to the taskbar application menu

I have an application. I would like to add my particular items to the right-click application's taskbar menu via C#. I want to add both permanent items and temporary items.
If I haven't made you to understand, this is the menu I am talking about:

This feature is called a JumpList and is for Windows 7. It is part of the Microsoft API. How to use this with C# has been documented thoroughly here and here.
In order to be able to deal with Jumplist classes in Windows Forms, you'd have to include these DLLs (Microsoft.WindowsAPICodePack.dll and Microsoft.WindowsAPICodePack.Shell.dll) in your project. You can get them from this CodeProject project or you can download the Open source library from WindowsAPICodePack which includes the source code that can be used to access Windows 7 and Windows Vista features. You will need to add two usings at the top of your code:
using Microsoft.WindowsAPICodePack.Taskbar;
using Microsoft.WindowsAPICodePack.Shell;
Any Jumplist consists of categories and each category has its own Jumptasks. There are two types of Jumptasks supported till now by WindowsAPICodePack; the JumplistLink and JumplistSeperator. A Jumptask represents an action to be performed by the user like openning a new instance of the application or launching another program. These Jumptasks are grouped in categories called JumplistCustomCategories.