I have a mono application developed with MonoDevelop as IDE. I'm working with windows 7.
I set a custom icon (embedded into the .exe).
When I run my application from inside MonoDevelop, all is fine.
But when I manually run "mono.exe ", my custom icon does not appears in the windows task bar. Instead, it appears a -it seems to me- predefined one.
How can I get my custom icon visible also when running my application from the command line? Starting always from inside MonoDevelop is not an option.
Thanks!
When you run your app from MonoDevelop, it runs using the .NET runtime. So Windows is able to pick up the app icon. When you run it using Mono, the executable app (from Windows' point of view) is Mono.exe. So you get Mono's icon.
I recommend that on Windows you run your app on .NET - even MonoDevelop runs on .NET on Windows. The Mono package for Windows is primarily intended for development (checking your app will run with Mono) and for specialized embedding purposes.
Related
After creating a new project using the "ASP.NET Core Web App" template, when I run the project, I want the console window to automatically be brought to the foreground. Since I'm mainly developing a web API, I don't want the browser to launch (which I've done in launchsettings.json), but do want the console window to show.
I've verified that this is the default behaviour when creating a .NET Core 6 Console app, yet I can't find the settings responsible for this desired behaviour.
It can be achieved easily just by changing a debug setting. It may be a little bit different in old versions of Visual Studio!
VS2022
1. Open Launch Profiles window:
2. Select relevant profile from opened window and change Launch browser setting(uncheck it)
3. Save the change if there is any Save button. and run the project.
I'm developing a C++ application that dynamically link against Qt, boost and Assimp. I compiled it in Release mode with /MD and it works fine on my computer. However, if I try to run it on another machine I get the 0xc000007b error (The application was unable to start correctly). I use Windows 8.1 on both machines but Qt5.3 and VisualStudio2013 are only installed on the 1st machine.
I built boost with
bootstrap.bat
b2 variant=release
I then used Cmake GUI to configure/generate a solution for Assimp that I later built using Visual Studio 2013.
Qt (32-bit version) was installed via the online installer. So everything (including my application) is built with a target 32-bit.
The folder that I copy to the other machine includes:
MyApp.exe
platform/
accessible/
assimp.dll
icudt52.dll
icuint52.dll
icuuc52.dll
kernel32.dll
opengl32.dll
libEGL.dll (cannot be found in Qt/5.3/msvc2012_opengl/)
libGLESv2.dll (same)
msvcp1XX.dll
msvcr1XX.dll
The Qt libs that I need (Core, GUI, Widgets, OpenGL)
If I copy these .dll/folders from Qt/5.3/msvc2012_opengl/, the app requires msvcp110.dll to start. If I add it and run it, I get the 0xc000007b error. But why msvcp110.dll instead of msvcp120.dll???
And if I copy the files from Qt/tools/QtCreator the app actually needs msvcp120.dll to run. But when it runs, it crashes at the beginning with:
QEGLplatformContext::init: eglError: 3005, this: 0x2e806b0
Which I guess is normal as you're not supposed to copy them from this location.
Does anyone know what I am doing wrong?
PS: I also ran vcredist_x86.exe on the machine without VS2013 before running my app. It installed successfully but nothing changed.
Thanks for your time and your help!
I am currently developing a Windows Store App that will eventually be targeted at the ARM devices when they are available. For now, I have been developing and testing from Visual Studio on my desktop computer and everything works fine. However, when I try to create an app package that I can pass along to others within my company for testing purposes, the application will not run properly.
The solution includes two projects. The first is a C++ project that is set to build a dll file. The purpose for this is to expose the Direct2D and DirectWrite libraries that seem to be unaccessible to a C# project. The second project is the C# project that references this dll for drawing functions and includes a XAML interface and most of the program logic. All of this works flawlessly on my development machine from within Visual Studio (and also when installing the package).
When I send the package files to other individuals within the company, the installation appears to work fine by installing with the PowerShell script. The tile appears in the start screen and the program will launch for a few seconds. The C# and XAML interface appears, but the DirectX portion of the application is not visible and the entire application shuts down within a few seconds. This makes me believe that the dll may not be installing or referenced correctly upon installation. I have checked the package file, and the dll file is included in the package after the build process is complete.
I have packaged a few different test programs (MSDN Samples) that have all installed on their machines, but we get the same results that they will not run (again, all samples run fine on my development machine when building them). The only test project that worked properly was a simple C# project that did not use DirectX at all. Any of the DirectX samples that I tried have all failed (including the native C++ samples that do not use C# at all).
To be clear, the process I use for building is going to Project -> Store -> Create App Packages and choosing the No option for uploading to the Windows Store.
Does anyone have any ideas on what might be going wrong with the build or installation process?
Thanks in advance for any help!
Does it work with the Metro Sideloader? I am not sure if it just adds a UI to the Powershell script, but it works for my team and me for testing...
Good luck!
Are you side loading a Debug version of your DirectX app onto a machine that does not have the Windows SDK installed? Visual Studio's default DirectX projects and the samples on MSDN both request the D3D11_CREATE_DEVICE_DEBUG flag when creating the D3D Device. Device creation will fail if the Windows SDK is not installed on the machine running the code.
Here are a few different options that will allow you to unblock yourself. Any one of these should give you the desired result:
Create a Release package and deploy that instead of a Debug package.
or - Go to DirectXBase.cpp and remove the D3D11_CREATE_DEVICE_DEBUG flag from the code.
or - Install the Remote Debugging tools for Visual Studio on the target machines. This will install the necessary SDK components to allow creation of D3D Debug devices. The other cool thing about this option is that once you're set up you won't have to create packages manually and side load them anymore. Just tell Visual Studio the name of your ARM machine and press F5 to deploy it remotely. More information here: http://msdn.microsoft.com/en-us/library/vstudio/bt727f1t.aspx
How are you deploying the native DLL with your project? Are you using project-to-project references? Can you verify that your DLL is ending up in the final package, in the root of the package application directory?
I recommend using Sysinternals Procmon to watch your application load on the target machine. If it crashes or fails, you can look in the log history for which DLL it is trying to load and failing. Typically this will show up as a repeated series of DLL load probes (it will try and load the dll from the application directory, and then proceed to try a number of other paths).
I'm developing an AIR application that will be run on both OSX and Windows (it's part of an internal tool chain). Part of the functionality of the application requires shelling out to external processes, so I've created a native installer package to get access to NativeProcess. The app also needs to automatically update when a new version is available, so I've used the NativeApplicationUpdater library.
I'd like to set up automated builds of the app. Unfortunately, it looks like building a native installer for a particular OS requires you to build it on that OS, making automated builds of both OSX and Windows versions impossible (at least on the same build machine).
If I could set up automated builds of a .air file, and then use that to update the native install, that would fit my workflow perfectly. My question is: is that possible? If not, are there any alternatives when it comes to auto-building a native install app?
Yes, you can build a native installer from the .air file:
adt -package
-target EXE or DMG
NATIVE_SIGNING_OPTIONS (windows only and optional)
output
input_package
See http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac1e63e3d128cdca935b-8000.html
I am trying to use MonoDevelop (2.4 beta 1) on Windows (7 x64) in order to test a .NET application on Mono (2.6.4). For some reason MonoDevelop is not using the Mono tool chain to build the application. It compiles it with the Microsoft tool chain - C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe. The project I am trying to build is a simple ASP.NET MVC application generated from the "New ASP.NET MVC application" template.
The "Runtime Version" dropdown in Project \Options->Build->General shows "MONO/.NET 35". What gives? Is there a way to change the .NET tool chain?
First of all, make sure that you have Mono installed. MonoDevelop does not include the Mono runtime, so you'll have to install it separately.
Once you have the Mono runtime installed, there are several ways of choosing the .NET toolchain to be used for building and running applications.
If you plan to build and run mostly on Mono, you can set the Mono runtime as default runtime for MonoDevelop. To do it, go to Edit->Preferences->.NET Runtimes, select the Mono runtime and click on "Select as Default".
If you plan to work on Mono only for some projects, you can temporarily switch the target runtime using the Project->Active Runtime menu, or by selecting it in the configuration combobox in the toolbar.