No Terminal Window, Compiling With gmcs Necessary For Mono? - winforms

I am compiling a Winforms app for use with Mono and using the .Net stuff built into Visual Studio 2008 for a Winforms app. Everything works fine, but I'd like to run without the terminal window opening.
Do I need to use gmcs to get this line to work:
-target:winexe
as seen here? Or can I do it with the built-in commands that Visual Studio uses for .Net?

In VS, make sure the project type is set to "Windows Application" and not "Console Application" on the project properties page.
If that doesn't fix it, try using monow.exe instead of mono.exe to run the application.

Related

Is it possible to use nvidia Nsight to debug cppwinrt directx12 applications?

I have a UWP cppwinrt app that is using directx12 to render a cube with a basic shader. I would like to use a graphics debugger to inspect the data being sent to this shader.
First I am trying to use the Nvidia Nsight debugger for visual studio 2017. The problem is that when I go to "Start Graphics Debugging" from the Nsight menu, the app immediately stop with an error saying: "Failed to launch UWP app (Could not terminate existing process)".
I am able to launch the Nsight debugger on a DirectX12 UWP app (C++/CX) created from the visual studio template though which is encouraging.
My cppWinRT app is rendering to a swapchain created using IDXGIFactory2::CreateSwapChainForComposition like so:
check_hresult(
m_factory->CreateSwapChainForComposition(
m_commandQueue.get(),
&swapChainDesc,
nullptr,
m_swapChain.put()
));
// associate DXGI swap chain with the XAML SwapChainPanel
check_hresult(
swapChainPanel().as<ISwapChainPanelNative>()->SetSwapChain(m_swapChain.get())
);
The swapChainPanel() is a winrt::Windows::UI::Xaml::Controls::SwapChainPanel xaml control.
Does anyone have an idea how this could be done?
UPDATE 8/13/2018:
I tried using Nsight with a different project from Microsoft that is very similar to mine, which you can find here: https://github.com/Microsoft/DirectX-Graphics-Samples/tree/feature_xaml_template/Templates/DirectX12XamlApp
It has the exact same problem as my project so it seems like the swapChainPanel XAML control is the problem.
I suspect that a possible workaround would be to present using a different swapchain when debugging, such as one created with IDXGIFactory2::CreateSwapChainForCoreWindow instead.

Winforms app: Wrong icon in start menu search

I'm building a simple Winforms application that deploys via msi (Visual Studio setip project). The msi creates a shortcut on the users desktop and the start menu.
Everywhere (desktop, start menu, taskbar when program is running, .exe file) the program icon is displayed correctly.
But not when I type the program name in the start menu search (see screenshot below). There some generic icon is displayed.
I quadruple-checked the icon set in Visual Studio > Winforms Project > Properties > Application and the icon for the shortcut set via the Visual Studio setup project. The .ico file has many different resolutions embedded, up to 512x512px. Since it's working fine everywhere else (except in the search) I can't think of anything als I could try.
Hans' comment was the solution for me. It seems that Windows caches the old/wrong icon. When I tried it on a clean Windows 10, it worked immediately.
Of course, I tried to clear the icon caches according to Application icon is blank when started from Process.Start or the script at http://www.winhelponline.com/blog/how-to-rebuild-the-icon-cache-in-windows but this did not work on my machine (even with a lot of restarts and killing of explorer.exe).

error LNK2019 :unresolved external symbol_main referenced in function tmainCRTsetup [duplicate]

I just installed Visual Studio 2012 express for Desktop. I can't see any place to create a GUI application with C++ ! Where is this "Windows Form Application" used to exists in Visual C++ 2010 ? Where are these drag and drop controls? I installed this because I got details telling this supports GUI intellisense (Visual C++: Unable to invoke method from another class)
It is an unsubtle hint that they want you to stop creating C++/CLI Winforms applications. The plumbing is still in place however, at least for VS2012 and VS2013. This might not be the case in a future one.
You can turn a CLR console application into a Winforms application with these steps:
Start with File + New + Project, CLR node, CLR Console Application
Project + Add New Item, UI node, Windows Form
Project + Properties, Linker, System, SubSystem = Windows
Project + Properties, Linker, Advanced, Entry Point = main
Change the pre-generated .cpp file to look like this:
#include "stdafx.h"
#include "MyForm.h"
namespace ConsoleApplication45 { // Change this!!
using namespace System;
using namespace System::Windows::Forms;
[STAThread]
int main(array<System::String ^> ^args)
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Application::Run(gcnew MyForm());
return 0;
}
}
Note that you'll need to change the namespace name to your project name. Press F5 to test. You can design the form as normal once everything checks out.
NOTE, Visual Studio 2015 has a nasty static initialization order bug in the CRT that can cause the app to crash instantly with an AVE at startup if the project contains any native C++ code. As yet an unfixed bug, the somewhat inevitable hazard of having these project templates removed. A possible workaround is to change the Entry Point (4th bullet).
For a project that targets x86, copy paste this string:
?mainCRTStartupStrArray##$$FYMHP$01AP$AAVString#System###Z
For a project that targets x64, copy paste:
?mainCRTStartupStrArray##$$FYMHP$01EAPE$AAVString#System###Z
Somewhere around VS2017 the designer fails to open a new form with a cryptic error message. Workaround is to build the project first, use Build > Build.
Remove the #include "stdafx.h" and this works well for VS 2022. The form must be hand coded since the Form Designer support was removed starting with VS 2012.

How do I create a C++/CLI Winforms app in VS2012?

I just installed Visual Studio 2012 express for Desktop. I can't see any place to create a GUI application with C++ ! Where is this "Windows Form Application" used to exists in Visual C++ 2010 ? Where are these drag and drop controls? I installed this because I got details telling this supports GUI intellisense (Visual C++: Unable to invoke method from another class)
It is an unsubtle hint that they want you to stop creating C++/CLI Winforms applications. The plumbing is still in place however, at least for VS2012 and VS2013. This might not be the case in a future one.
You can turn a CLR console application into a Winforms application with these steps:
Start with File + New + Project, CLR node, CLR Console Application
Project + Add New Item, UI node, Windows Form
Project + Properties, Linker, System, SubSystem = Windows
Project + Properties, Linker, Advanced, Entry Point = main
Change the pre-generated .cpp file to look like this:
#include "stdafx.h"
#include "MyForm.h"
namespace ConsoleApplication45 { // Change this!!
using namespace System;
using namespace System::Windows::Forms;
[STAThread]
int main(array<System::String ^> ^args)
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Application::Run(gcnew MyForm());
return 0;
}
}
Note that you'll need to change the namespace name to your project name. Press F5 to test. You can design the form as normal once everything checks out.
NOTE, Visual Studio 2015 has a nasty static initialization order bug in the CRT that can cause the app to crash instantly with an AVE at startup if the project contains any native C++ code. As yet an unfixed bug, the somewhat inevitable hazard of having these project templates removed. A possible workaround is to change the Entry Point (4th bullet).
For a project that targets x86, copy paste this string:
?mainCRTStartupStrArray##$$FYMHP$01AP$AAVString#System###Z
For a project that targets x64, copy paste:
?mainCRTStartupStrArray##$$FYMHP$01EAPE$AAVString#System###Z
Somewhere around VS2017 the designer fails to open a new form with a cryptic error message. Workaround is to build the project first, use Build > Build.
Remove the #include "stdafx.h" and this works well for VS 2022. The form must be hand coded since the Form Designer support was removed starting with VS 2012.

Debug Visual Studio or Blend Silverlight / WPF designer load errors?

Is there a way to debug Visual Studio or Blend so I can figure out where XAML designer load errors come from in my code?
The stack traces are often useless.
Thanks...
Use two VS2010 instances. Load one with your main app probject or a test harness application project and load the other with your controls project. Having built the controls project reference the debug dlls in your other project. Debugging from the VS2010 instance holding the controls project attach to the VS2010 instance holding the test application.
Place your break points as you like.
Now drive the test application instance of VS2010 as you would when building yout controls into an application, when your controls are load their code will execute and you can start stepping the code. You can do a similar thing when working with your controls in Blend just attach to the Blend instance.
In VS, first go to Debug->Exceptions and check the box for "Thrown" for CLR Exceptions. This will break into the debugger for exceptions caught by the Blend/VS app. Then do Debug->Attach To Process... and find the instance of Blend or devenv that has your solution open. Once the debugger starts up you can open the XAML file in the designer and debug against it.
Here are another two cents. Just make sure that the Options->Debugging->General->Enable Just My Code is unchecked in the instance you are using to attach to the designer's process.
I found both answers useful. Just adding my 2 cents - In the VS copy that you're using to attach to the designer, I needed to select the code type manually (Managed, v4.0 in my example) in the Attach To Process dialog to get the desired result. For some reason the default for devenv was Script, T-SQL. Looking at the date of the OP and original answers, it may be that an update to VS caused this change... just speculating.

Resources