I'm using Visual Studio 2015 professional, and my issue is similar to https://developercommunity.visualstudio.com/t/vs2019-winforms-designer-inherited-forms-issue/513785 . However, I cannot use the workaround in the thread because I'm referencing another class built only for x64 platforms in the parent form.
If I switch to "AnyCPU" platform, the compiler would complain about not able to find the x64 assembly.
If I switch back to "x64" platform, the compiler would complain about not able to load the parent form class.
Any ideas or this is just impossible to achieve in Visual Studio?
Related
I have a macbook M1PRO, and I need to debug .net2.0 and .net 3.5 codes in its Windows11 virtual machine, but I can't set up a code runtime environment。
I have installed .net framework 3.5 in the "enabling or disabling windows features" in the control panel, but its existence is still not recognized in visual studio.
enter image description here
enter image description here
If I don't use a simulated x64 virtual machine or another x64 computer, I just want to run all programs on one computer, how can I solve it？
If you create a x64 VM, then you have to install windows 11 (not arm based version).
then install visual studio for windows. (again, the non arm version).
At that point, you can develop with .net framework 2.0-4.8.
You can't create, run, use, enjoy, develop .net framework asp.net applications unless you running a windows VM, and using the windows version of VS.
You can ONLY run (and develop) .net core applications on arm based, or other computers, and NOT .net framework applications.
given that you looking to develop (or work on) a x64 .net framework, and quite a older version?
Then you have to create a x64 (not arm) based VM, and install the x64 bit version of windows (again, NOT the arm based version of windows). You then install Visual Studio for windows.
The above will thus allow you to develop and work on .net framework applications, such a as asp.net .net framework based application.
I have MS Visual Studio 2022 (64-bit) v.17.4.2 crashing while opening a form in design mode in Windows Forms project (.NET Framework 4.x).
This form has many UserControls. The Windows Forms project is a 64-bit one recently converted from 32-bit Visual Studio 2019 project. The application and this problematic form work well when running from within Visual Studio 2022 (Ctrl+F5) or within standalone Windows Forms .NET Framework 4.x application.
The crashing issue should be somehow caused by one of the UserControls but while crashing Visual Studio 2022 doesn't produce any logs - it just crashes silently.
How can I capture/log any info on such an issue to modify my UserControls design/code behind?
I must note I have another Visual Studio 2022 Windows Forms .NET Framework 64-bit project with a (much) more complicated main form and related UserControls design and this form gets opened in design mode without any issues.
hi not sure about VS 2022 but for vs 2019 you have to set the target cpu to x86, edit the form then set it back to x64 to run, not ideal but seems to work
I have a project based on Qt which use QWebEngine. For compiling this project i've installed Visual Studio Express 2015 and have configured kits. My project is built, all is fine. But now i need to compile my project for Windows XP platform. I know, that for doing this it is needed to change toolset from v140 to v140_xp.
How can i set the toolset from qtcreator?
I tried to determine the difference in compiler options in both cases. For doing that I've created test project in Visual Studio. There i change the toolset and look at Project Properties -> C/C++ -> Command Line Options. But seems that nothing changes there.
Qt WebEngine module does not support Windows XP targeting, so this won't work anyway. Even if it did, you'd need to build a copy of Qt that targets Windows XP - otherwise your application will target Windows XP, but not the Qt library it uses, and it won't work that way.
For completeness sake, here's how you'd do it assuming that you got Qt built targeting Windows XP:
There only two ways to do it currently without patching Qt Creator itself:
Execute Qt Creator with environment variables already setup up for the XP toolset enabled for command line use. I.e. target XP from command line, and launch Qt Creator from there.
Add relevant environment variable settings to the Build environment of the project in Qt Creator.
The details of environment variables needed to target Windows XP are given e.g. here.
For Windows XP portability, you should be using the semi-maintained for of the qtwebkit module. It builds and works on XP, and works with most recent Qt IIRC.
Note: It's certainly possible to target XP using WebEngine and Angle, but it requires lots of patches to current Qt. It's not an insignificant effort, and you'd definitely want to test it on the graphics cards that you intend to target - the DirectX 9 drivers on some of those machines are buggy, and while the code is correct and compiles and runs, it may not work on some systems. I'd say that it's absolutely not worth the effort.
In VS there is an editbin utility, which could be used as follows
editbin file.exe /SUBSYSTEM:WINDOWS,5.01 /OSVERSION:5.1
My setup consists of Microsoft Visual Studio Express 2013 and Qt 5.5.1. For the Debugger(s) I use CDB from the Windows SDK. I use both toolchains, 32bit and 64bit.
To clean up my machine, I recently deinstalled all Microsoft Visual Studio stuff including the debuggers. Now, after the new installation of all the tools, I am not able to set up the 64bit debugger anymore. The interesting thing is that both debuggers are correctly autodetected under the Debuggers tab Tools -> Options -> Debuggers.
Under the Kits tab, I see the yellow triangle on the 64bit entry. I also see that None is selected in the Debugger line. But I am not able to change this setting because it is deactivated.
I finally found a solution to this problem by editing a Qt Creator configuration file manually. The file toolchains.xml is found here in Windows 7:
%APPDATA%\Roaming\QtProject\qtcreator
Additional Note:
Since the original post, I've updated to Visual Studio 2015 Express and Qt 5.6. This environment is a lot simpler to set up than VS2013.
I am using visual studio 2010 Express. I have created a website in asp.net.It works in XP but not in Windows 7 premium(64-bit)
I am facing the same problem mentioned here.
I tried to register the DLL using regsvr32 but shows an error as
The Module "c:\MyProject\bin\MyDll.dll" was loaded but the entry-point
DllRegisterServer was not found.
Make sure that "c:\MyProject\bin\MyDll.dll" is a valid DLL or OCX and
then try again.
Also i didnt find any options under properties to set platform target or Target CPU so that i can convert my website to run for 32bit platform.
I am new to ASP.NET, Please help...
First notion would be that your app is running under a 64-bit application pool in IIS that does not have 32-bit apps enabled, and in that case 32-bit DLLs cannot be loaded into a 64-bit process space. Check that the application pool hosting your site allows 32-bit applications.
VS 2010 Express should be creating 32-bit executables by default; although I have not personally used it, I believe I have read that to build 64-bit executables in the 2010 Express versions you must download an additional SDK, so you're likely building a 32-bit target, thus causing the problem described.
I got this dialog trying to run the Visio x32 FlowChartSampleVBNET add-in. The dialog appeared with CLSID{00024500-0000-0000-C000-000000000046} which pointed to Excel. I had Excel x64 installed on my x64 machine. Apparently, the mismatch between Visio x32 and Excel x64 was causing the problem. After uninstalling Microsoft Office 2013 x64 and reinstalling Microsoft Office 2013 x32, I could run the add-in without error.
Enabling 32-bit application in IIS did not worked in my case!
When I have installed crystal report for visual studio and crystal report runtime engine (64-bit) worked in my case!
Some other suggests that, this problem could be resolved by installing both 32-bit and 64-bit runtime engine!
You can find similar issue here Retrieving the COM class factory for component with CLSID {XXXX} failed due to the following error: 80040154