We Keep Coding

Outlook addin doesn't load and also doesn't show as disable or inactive, even though correct registry was created

I have created an outlook VSTO Addin using visual studio 2012, .net framework 4.5 . It loads correctly,on various machine that I have tested. But on two client machines it is not loading, even though correct registry entry has been created under path.
HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\
Also, the plugin is installed correctly, it shows up in the Add or remove programs.But the addin is not visible even in the inactive or disable list in outlook.The load behavior is still 3 in the registry.So, what could be the cause of the issue?

There is a nice post on msdn to learn how to debug VSTO addins : see here.
Essentially you can display loading-time error message for your add-in by setting the environment variable (on your customer machine) VSTO_SUPPRESSDISPLAYALERTS to 0. For an example see here .
See also this post : How to troubleshoot a VSTO addin that does not load?

Debugging .NET crash that does not happen within Visual Studio IDE

When I ran my C# WinForms executable outside of the Visual Studio IDE for the very first time, I received the following dialog:
"<Application> has stopped working, Windows can check online..."
So I attached to the process using Visual Studio's Attach to Process, which showed that the program had suspended within InitializeComponent() (but did not provide further clues).
I edited the application, placed a try/catch block around the aforementioned code, which allowed me to print the following MessageBox output:
As you can see, this showed that the application is not able to find a DLL it needs.
My question: Could I have achieved this result without modifying the application (that is, without the try/catch block printing out the specifics)? Could Visual Studio Attach to Process functionality guide me to the specific problem being the missing DLL? If so, how?

This information can be found from fusion logs, if you enable them. Fusion logs are helpful in diagnosing if an assembly load fails because of missing dependencies.
Also, sometimes event viewer has useful information.
https://msdn.microsoft.com/en-us/library/e74a18c4%28v=vs.110%29.aspx

VS 2010 designer error 'Could not find type XYZ' in Windows7. Works fine in XP

I'm stuck on a problem in VS 2010 C# .NET. I've had a project on Windows XP that includes forms, classes and a handful of my own custom components. These components are simple extensions of built-in MS components (e.g. DataGridViewEx as an extension of DataGridView). Everything has worked fine in XP. I'm trying to port this project over to VS 2010 on Windows 7 / x64. I've got the solution to compile OK on Windows 7, however in design mode, when I open a form that contains one of the custom controls, I get an error 'Could not find type XYZ.DataGridViewEx. Please make sure that the assembly that contains this type is referenced.' XYZ is the namespace I use for these controls and it is the same namespace as the forms that are using the controls. All are part of the same VS project.
When I open a form in the same project that does not contain one of these custom controls, that form opens OK in the designer, and I see the custom controls along the left side in the toolbox. However if I then try to drag one of these controls into that form, it pops up an error message box 'Failed to load toolbox item 'DataGridViewEx'. It will be removed from the toolbox.' And then it gets removed from the toolbox.
Everything was always working fine in VS solution in XP. This problem only occurs in the VS solution in Windows 7 / x64.
I don't understand why it complains about not being able to find the component, since the component is part of the same project. That's a valid thing to do, isn't it?
I've search the web/forums and found cases of the 'Could not find type' error, but it seemed to be caused by a different issue, and I haven't yet found a way to get rid of the error.
Any help/tips are much appreciated!

If your project is targeted at 64 bit, you need to build for 32 bit and choose the 32-bit solution while doing your GUI editing. This is because studio is 32-bit so cannot load 64-bit controls.

Ive run into this before, be sure that in your Form.Designer.cs code file, that each call to your custom controls are done so as absolute calls. For example:
Namespace.CustomControl control;
Rather than
CustomControl control;

Look at your references and find any that have exclamation point icons. Remove the bad references and add them back to your project.

Have you tried disabling UAC completely (running IDE as Administrator + disabling UAC just in case).
Also - always use Fusion Log for tracing assembly loads! See http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.71).aspx for how to set it up

Did you rebuild your components from scratch?
Are the projects included?
Are they all building?
Are they all building on the same platform (x86 vs x64)?

Set the default built to x86 and that should fix it.

Clean the solution
Build the project containing the Control
Add the control to the toolbox/form
See if this works.

For anyone who with similar issue(s). I just came across this in VS 2013 (VB side) on an x86 PC. As mentioned above, I toggled from 'anyCPU' to 'x86' and the form designer opened right up. Simple, but probably wouldn't have tried it without the above post(s). For what it's worth, I toggled back to 'anyCPU', and as yet have had no recurrences...

I faced the same error, can't able to Build my application.
So searched here, Says to change the solution platform X64 or X32.
But in my case the Solution platform only shows Any CPU and configuration manager option only
But i simply change the solution configuration.
Debug => Release
then
Release => Debug
Finally clean and rebuilt the solution. Its works for me!!:)

While the top answer from #richard-whitehead is correct that the 64bit editor cannot load the 32bit controls which is why you're seeing the error, there is another way to have Visual Studio edit 32bit GUI controls in a 64bit GUI project as described here:
https://stackoverflow.com/a/26539992/2280961

VS 2010 not responding once i open my project ..exception (0x76a0b9bc in devenv.exe)?

when i start visual studio 2010 c# .. and open my application i got this. it stopped responding and gives me that message in the picture once my application is opened but other application works fine.
then i debug visual studio 2010 .. and i got the exception
Unhandled exception at 0x76a0b9bc in devenv.exe: 0xE0434352: 0xe0434352.
EDIT: i tried to open the .exe file in project folder in debug folder and i got this.
how to fix that ? what should i do ?
thanks in advance.

Visual Studio is vulnerable to certain exceptions that are raised in design mode. Hard to categorize them, it is an immediate crash to the desktop. The exception code says as much, 0xe0434352 is a low-level managed code exception. You'd normally work around it by checking-in an earlier revision of your control and pay extra attention to code that needs to be disabled at design time by checking the DesignMode property. Your screenshot shows as much, seems like the control is actively displaying runtime info while in design mode. Risky.
If you want to debug it then you can by starting another instance of Visual Studio and use Tools + Attach to Process to attach to the first one (devenv.exe). Debug + Exceptions, tick the Thrown boxes for CLR exceptions and Win32 exceptions. Switch back to the first instance and load your project.

i've figured out what happened .. my form got 3 usercontrol that i made before.. one of those usercontrol has a customized progressBar which is a library .. for some reason that library stopped working .. so i removed it .. then added again from that usercontrol .. then the application worked.

Issue with debugging Visual Studio 2010 solution that utilises FileDialog from the Vista API

I have a WinForms C# Visual Studio 2008 (.NET 3.5) solution that is to be upgraded to Visual Studio 2010 (.NET to remain at version 3.5). This solution utilises the FileDialog from the Vista API for two reasons:
When running the application in Windows XP, the expectation is to provide the user with a Windows XP look-and-feel file dialog. When running the same application in Windows Vista and 7, the file dialog is to have a Vista look-and-feel.
More importantly our application allows a user to open up a project file, which can either be a local file (stored on the user's machine or on a USB device), or a server project (hosted in MS SQL Server). To achieve this, we use the Vista API as we can access the event handler of the file-type drop-down-list control. Hence the implementation is such that the user is presented with the open file dialog, and when they select the "Server" option from the file-type drop-down-list, the open file dialog closes, and a different dialog opens, allowing the user to select the server they wish to connect to, and the server project.
In Visual Studio 2008 when debugging the application, there are no issues with the Vista API. When the solution is upgraded to Visual Studio 2010 (running in Windows 7), the user attempts to debug the application, and the user wishes to access the Vista API open file dialog, the application crashes with an ArgumentException being thrown with the following message: "Value does not fall within the expected range". Strangely enough when the user runs the solution without debugging (Ctrl + F5) from Visual Studio 2010, no exception occurs. The "offending" code is:
internal void DoFolderChange(IFileDialog dialog)
{
IShellItem ppsi = null;
string ppszName = string.Empty;
dialog.GetFolder(out ppsi);
// Exception occurs here
ppsi.GetDisplayName(NativeMethods.SIGDN.SIGDN_FILESYSPATH, out ppszName);
OnFolderChange(ppszName);
}
I have tried some Google searching, but to no avail. I have available a sample Visual Studio 2010 solution with the Vista API, and the issue also occurs in this solution. The sample project can be downloaded (in ZIP form) from here. To reproduce the issue:
Debug the solution in Visual Studio 2010.
Once the "Vista Api Demo" is launched, click on the "Dialogs" tab.
From the "Vista Look" column situated at the right hand side of the "Dialogs" tab, click on the "Open File" button.
A dialog with the message "File type was changed to 1" will appear. Click on the OK button.
Observe that at this point the application crashes, with the exception thrown from the DoFolderChange(IFileDialog) method in clsFileDialog.cs.
My apologies for the long-winded post, but I needed to explain the whole background of why the Vista API file dialog implementation is required. I appreciate any help in resolving this issue, as my development team is looking at working with Visual Studio 2010, and we developers do not want to be fiddling around with attaching and detaching the debugger just to bypass this issue.

I came across this and I figured out a fix in my case.
Original Code:
OpenFileDialog fdlg = new OpenFileDialog();
string tempDirectoryName = #"..\SomeFolder\"; /* Note, the use of a relative directory*/
fdlg.InitialDirectory = tempDirectoryName ;
Nullable<bool> result = fdlg.ShowDialog();
I then changed it to:
OpenFileDialog fdlg = new OpenFileDialog();
string tempDirectoryName = #"..\SomeFolder\"; /* Note, the use of a relative directory*/
string massagedDirectoryName = System.IO.Path.**GetFullPath**(tempDirectoryName);
fdlg.InitialDirectory = massagedDirectoryName; /*Note, this is now the full folder name */
Nullable<bool> result = fdlg.ShowDialog();
And it did not bomb on me anymore.
Mine was almost same scenario.
My scenario:
Code was WPF app under VS2008 and worked. (3.5 Framework was the Target Framework)
I up-converted to code to VS2010 (4.0 Framework was the Target Framework). Then this new issue arose.
Both code bases were running on Windows 7 x64.
.............
My full error was:
Value does not fall within the expected range.
at MS.Internal.Interop.HRESULT.ThrowIfFailed(String message)
at MS.Internal.AppModel.ShellUtil.GetShellItemForPath(String path)
at Microsoft.Win32.FileDialog.PrepareVistaDialog(IFileDialog dialog)
at Microsoft.Win32.FileDialog.RunVistaDialog(IntPtr hwndOwner)
at Microsoft.Win32.CommonDialog.ShowDialog()