I am trying to install Qt4.8.7 for Windows 10 and I am having some issues with installing the corresponding compiler.
I got the Qt4.8.7 installer from this link: https://download.qt.io/archive/qt/4.8/4.8.7/ and I have tried working with the MSVC2010 and the mingw versions. For the MSVC2010 version, I followed this guide https://wiki.qt.io/How_to_setup_MSVC2010 (with a lot of dead links) and installed the compiler alongside the MSVC service pack 1 and Windows SDK 7.1. I have not been able to find an installer for Visual Studio 2010 or the VS service pack 1. Qt studio recognises the version of qt I have installed alongside the corresponding MSVC2010 x86 compiler but when I compile I get this error for a missing header: "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\intrin.h:26: error: C1083: Cannot open include file: 'ammintrin.h': No such file or directory".
For the mingw version, I have not been able to find the correct version "mingw482" and other versions I have tried do not seem to be compatible. I have tried mingw installer programs as well as using the QT online installer to try and find the correct version but I haven't had much luck when compiling.
Has anyone got qt4.8.7 running on windows recently? If so, could you please point me in the right direction for installing the correct compiler?
Many thanks.
Here a short description for getting it to work with Visual Studio 2008 and the newest Qt Creator 4.13.
You will need:
Visual Studio 2008 Express for the build tools, there are no standalone build tools as far as I'm aware
Qt 4.8.7 precompiled for VS2008 from this link to Qt archives at the time of writing this the version you need is called "qt-opensource-windows-x86-vs2008-4.8.7.exe"
Any Windows debugger cdb.exe
Steps (all absolute paths are standard installation paths):
Install VS2008
Install Qt 4.8.7
Open your Qt Creator go to Tools->Options...->Kits->Tab Compilers and search for "Microsoft Visual C++ Compiler 9.0", it probably won't be there so you will need to add it by hand by looking for the vcvarsall.bat of this compiler. You will find it in C:/Program Files(x86)/Microsoft Visual Studio 9.0/VC/vcvarsall.bat. Repeat for C, C++, x86 and x64. Press save
Open the Qt-Versions tab and look for Qt 4.8.7 Version. It will probably not be there again so add it by hand by selecting the qmake.exe from C:/Qt/4.8.7/bin/qmake.exe. Press save
Open the Kits tab and add a new kit. Select your Qt 4.8.7 version and the MS compilers for C and C++, your favorite debugger and input the Qt-makespec win32-msvc2008. Press save again
Now you should be able to compile your project from Qt Creator and Qt-colored-commandline. For integration of MSVC 9.0 into Visual Studio 2015 and newer you will also need to install Visual Studio 2012 Express. In that order:
VS2008
VS2012 (Here MS programmed in some magic so newer VS can see older build tools)
VS201x
It could work in any other order but don't rely on it. Also it could just flat out not work and you will waste a week of your life to fix it; but then it will work.
Haven't tested it but I could imagine the same workflow will work for VS2010.
I have encountered a weird behavior with VS for Mac. This is how I repro it:
Built a .NET Standard 2.0 NuGet package using VS2017. Package is called "MobileApps.Auth 1.0.0"
Pushed the NuGet to our company NuGet server
Switched over to the Mac and launched VS
On the Mac; Built a Xamarin Forms app (shared project is also .NET Standard 2.0)
Added reference to the .NET Standard 2.0 NuGet
ERROR:
Package MobileApps.Auth 1.0.0 is not compatible with netstandard2.0 (.NETStandard,Version=v2.0). Package MobileApps.Auth 1.0.0 supports:
- monoandroid81 (MonoAndroid,Version=v8.1)
- xamarinios10 (Xamarin.iOS,Version=v1.0)
I have zero clues as to why the NuGet would support monodroid81 and xamarinios10. It's a .NET Standard 2.0 library that reference Xamarin.Forms.
If I instead remain on the PC and run steps 4 and 5 in Visual Studio 2017 all is peachy.
This smells like a bug in VS for Mac. Has anyone else seen this?
Overall, having spent a few days building NuGet packages, based on .NET Standard 2.0, both on the Mac and PC I get the overall feeling this doesn't really work on the Mac. The reason I built the NuGet on VS2017 is because NuGet packs built on VS for Mac includes all kinds of facades that causes msbuild to fail due to conflicts (same identifiers found in multiple referenced assemblies).
[EDIT 1]
This is the NuGet layout when package built on VS4M:
_rels (empty folder)
[Content_Types].xml
lib
netstandard2.0
MobileApps.Auth.dll (my lib)
(+ 113 other dlls)
MobileApps.Auth.nuspec
package
services
metadata
core-properties
5bd1f861cd8a425f854c073a4a5f3e0e.psmdcp
And this is the NuGet layout when built on VS2017:
_rels
.rels
[Content_Types].xml
lib
netstandard2.0
MobileApps.Auth.dll (my lib)
MobileApps.Auth.nuspec
package
services
metadata
core-properties
5bd1f861cd8a425f854c073a4a5f3e0e.psmdcp
The difference is that VS4M includes 113 extra dlls in the netstandard2.0 folder while VS2017 doesn't. How can I control that?
[EDIT 2]
This is the .nuspec from within the .nupkg, built with VS4M:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<id>MobileApps.Auth</id>
<version>0.1.1</version>
<title></title>
<authors>Jonas Rembratt</authors>
<owners>Jonas Rembratt</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>bla bla</description>
<summary></summary>
<releaseNotes></releaseNotes>
<copyright></copyright>
<language></language>
<dependencies>
<group targetFramework=".NETStandard2.0">
<dependency id="Xamarin.Forms" version="3.1.0.697729" />
<dependency id="System.ValueTuple" version="4.5.0" />
</group>
</dependencies>
</metadata>
</package>
Ok, here's the latest outcome from my experiments with NuGet/VS4M/VS2017. One problem seemed to be that VS4M included 113 libs in the NuGet package so I wanted to see if that was the problem or not. I first tried to simply renamed the .nupkg file into .nupkg.zip on the Mac, then unpack it, then remove the .nupkg, then remove the 113 libs in lib/netstandard20 leaving only my own dll in there. I then simply compressed the folder again into "MobileApps.Auth.nupkg.zip" but it seems Finder won't take kindly to then simply removing the ".zip" suffix. So, I simply moved the .zip over to Windows and removed the ".zip" suffix there before moving it back to MacOS. In the end I'm left with a .nupkg that in essence looks just like the one I generated with VS2017 (see OP), that is a package that contains only my own .dll file.
This works.
So, the problem now is that:
This leaves me with having to go through a tedious process of manually removing all unecessary .dll files from my NuGet package whenever I re-generate it. Is there really no way to configure the 'nuget' build to exclude these libs in the first place, like VS2017 does?
Why didn't it work when I built the .nupkg file on VS2017 and then tried to use it with my projects in VS4M?
Error:
C:\WebApp\WebApp.csproj : error : The SDK 'Microsoft.NET.Sdk.Web' specified could not be found. C:\WebApp\WebApp.csproj
I am trying to open Dotnet core project and I am getting the above error.
I have installed the latest SDK from https://www.microsoft.com/net/core#windowscmd
I have checked the path for dotnet cmd and it works fine.
Am I missing something? Let me know if you need more information.
The target framework is set to .NET 4.5.2
I stumbled upon this issue a number of times recently. Here's a brief list of the workaround I found (one of them always worked until now):
Install the right .NET Core SDK: Either the latest version or the version required by your project.
Clean-up obsolete .NET Core versions: Go to Control Panel and uninstall previous .NET Core SDK/Runtime versions (as long as you don't use them anymore).
Create a Global.json file: Add a new global.json file to your project's root with the following content (replace the .NET Core version build with the one you want to run the project with):
{
"sdk": {
"version": "2.0.5"
}
}
Rename the SDK reference: Open your .proj file and replace <project sdk="Microsoft.NET.Sdk.web"> with <project sdk="Microsoft.NET.Sdk"> .
Add the MSBuildSDKsPath Environment Variable: The dotnet CLI sets the MSBuildSDKsPath environment variable when invoking MSBuild: however, a December 2016 patch changed the CLI behaviour so that it will respect an existing environment variable, if it has already been set: this will allow the developer to “force” the CLI to use a specific SDK.
Check your PATH: Verify that both C:\Program Files\dotnet and C:\Program Files (x86)\dotnet are in the PATH environment variable.
For additional info regarding the issue and other viable fixes check out this blog post that I wrote on this topic.
I agree with the comment on Sundeep's answer, you shouldn't have a global.json file in your project anymore.
It seems as though installing the .NET Core 2.0 SDK is causing issues with the PATH. Verify that C:\Program Files\dotnet and C:\Program Files (x86)\dotnet are in the PATH environment variable. In my case, these values were already present under System Variables so I added them to User Variables and rebooted my machine. This resolved my issue.
As suggested in the comment, I updated global.json file as shown below
{
"sdk": {
"version": "1.0.0"
}
}
Also, I had to remove the <ItemGroup> which contains wwwroot files path in .csproj file.
Reload the project and it works like a charm!
I've encountered the same problem, I just rename <project sdk="Microsoft.NET.Sdk.web"> to <project sdk="Microsoft.NET.Sdk"> on csproj
another situation:
https://stackoverflow.com/a/55529011/2971851
issue details: 2.1.6xx & 2.2.2xx version of the SDKs are only supported
on Visual Studio 2019. VS 2017 needs 2.1.5xx & 2.2.1xx versions of the
SDK.
How to fix the issue? Install 2.1.5xx version of the SDK if you are
targetting a 2.1 app Install 2.2.1xx version of the SDK if you are
targetting a 2.2 app.
and according to the official document:
Note: If you are a Visual Studio user, there are MSBuild version
requirements so use only the .NET Core SDK supported for each Visual
Studio version. If you use other development environments, we
recommend using the latest SDK release.
Do not uninstall previous SDK versions!
When I followed the 2nd step suggested in Darkseal's answer, uninstalling the previous SDK versions, it caused an "expected imports are missing" fatal error every time I opened up my project, so I needed to repair my Visual Studio, since installing the old SDK versions again kept popping up this error...
Also the other steps mentioned in that answer did not make any difference (both dotnet references were present in the environment variables and MSBuildSDKsPath was not needed for me).
Install the proper SDK version and select it in the Solution's Properties
As Jyoten mentioned I was using VS2017 x86 version and my SDKs were x64.
However, this was not the only issue, it seems there's some incompatibility with some SDK versions and VS2017. Having installed SDK v2.2.203 and v2.2.202, they would never showed up in the Target framework dropdown when I double-clicked the Properties on my project's solution (in the Solution Explorer (Ctrl+Alt+L)).
So I needed to install v2.2.105 x86 as mentioned in this answer, for it to show up in that dropdown.
Once it did, the solution that was requiring .NET Core v2.2 worked properly (did the Build normally).
I had this issue when I had to open a .Net Core 1.0.4 project in VS2017.
When I installed 1.0.4 SDK, i chose the x64 version which placed the sdk files in 'c:\Program Files\dotnet' ...
but my VS2017 was 32bit and was therefore looking for the sdk in 'c:\Program Files (x86)\dotnet'.
Once I installed the 32 bit version of the SDK it worked fine.
I was running into an issue where creating a new ASP.NET Core 2.0 project was giving me an error The SDK 'Microsoft.Net.Sdk.Web' specified could not be found, and leaving me unable to open the project in Visual Studio. The problem was the project was created in a folder that contained a global.json file, tying the SDK version to 1.0.0.
Deleting the global.json, or updating it to 2.0.0, fixed the issue. Be sure to check parent folders too - if any parent folder contains a global.json, the SDK version specified in the "closest" folder will be used.
I was getting this error in Visual Studio Code.
I was able to find the issue by setting the OmniSharp log settings in VS Code to debug. Once I did that I could see that it wasn't finding Microsoft.Build.Resources.dll.
I installed MS Build by repairing my VS 2017 Community installation. That fixed it.
uninstall and reinstall microsoft .NET core SDK.
then restart visual studio.
this works for me.
Choose the proper SDK according to your Visual Studio and Operating System. I downloaded the correct version from here https://dotnet.microsoft.com/download/visual-studio-sdks and after that .Net Core appeared in target frameworks list (there is a strict dependence between sdk version and VS version, so be careful).
I have solved this issue by,
go to this site, https://dotnet.microsoft.com/download
In that, install both .NET Core Runtime and .NET Core SDK.
After you install that, Open the Visual Studio 2017 with an administrator, Now The problem has been gone😊
I edited the .csproj file and changed netcoreapp2.2 to netcoreapp2.1 in this stanza & then I was able to get it working.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
Install the proper SDK version and go to below links
https://dotnet.microsoft.com/download/dotnet-core/thank-you/sdk-3.1.403-windows-x64-installer
https://dotnet.microsoft.com/download/dotnet-core/thank-you/runtime-desktop-3.1.9-windows-x64-installer
This worked for me:
Make sure that the .NET folder where SDKs are and Visual Studio are
in the same program files (x86) or program files.
Provide the path to the SDK in the environment variable.
If anyone else stumbles upon this issue (including future me), I had the same problem and tried literary every solution proposed here and nothing worked. Finally what fixed the issue for me was deleting NuGetFallbackFolder in C:\Program Files\dotnet\sdk.
After deleting that folder, everything just started to work magically.
I had this error when from old project (in .NET 4.7.2) I was trying to do:
var project = new Microsoft.Build.Evaluation.Project(someDotNet6ProjectPath);
The solution was to upgrade Microsoft.Build packages.
I have an older extension that i would like to get to work in VS 2017. To be able to do this i understand that i will have to use the new VSIX Manifest v3. The extension works fine in 2015 Update 3. To update it I've done the following:
Open the extension source in VS2017. I'm prompted to do a one-time upgrade, which is completed successfully
Use NuGet to update the Microsot VSSDK BuildTools from 14.x to 15.x
Add the Prerequisite block to the source.extension.vsixmanifest file containing Microsoft.VisualStudio.Component.CoreEditor
Update the Installation target to also support the new Visual studio like so
<InstallationTarget Version="[15.0,16.0)" Id="Microsoft.VisualStudio.Enterprise" />
Builds successfully, but once i open the vsix file in my debug folder, get a message telling me
The file is not a valid VSIX package
If i open up the file using WinRAR i can see that the two mandatory files catalog.json and manifest.json is not in there as they are supposed to in the new v3 format.
What am i missing here ?
It turned out that my problem was, that inside the vbproj file (or csproj for most others) there was an import at the top like so:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\..\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\Microsoft.VSSDK.BuildTools.props" Condition="Exists('..\..\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\Microsoft.VSSDK.BuildTools.props')" />
<Import Project="..\packages\Microsoft.VSSDK.BuildTools.14.3.25407\build\Microsoft.VSSDK.BuildTools.props" Condition="Exists('..\packages\Microsoft.VSSDK.BuildTools.14.3.25407\build\Microsoft.VSSDK.BuildTools.props')" />
....
As you can see this project file has imports for both the new version and the old one of the BuildTools. I'm not sure why this happens, as all i did was update the VSSDK BuildTools via NuGet. I also tried to completely uninstall the BuildTools ticking Force uninstall but it seems to have remained through everything I tried.
So if you experience similar problems, look at your vbproj/csproj file if it has imports for older versions of the Microsoft.VSSDK.BuildTools
You must also upgrade the BuildTools package, the error you get indicate that this did not happen: https://learn.microsoft.com/en-us/visualstudio/extensibility/how-to-migrate-extensibility-projects-to-visual-studio-2017
So I thought upgrading Qt and Qt Creator was a good idea since I used an older version of both.
I re-installed everything as I should and realized that Qt 5 is only for VS2010 for Windows which I have never worked with since I have been sticking with minGW up to this point,
I then realized my problems that my project wouldn't compile and run so I tried to download the 4.8.4 version with minGW, but that complained that:
"The installer could not find a valid c:\MinGW32\include\w32api.h
(Only versions with W32API3.13 are supported)"
and further I did not get creator when I installed it either.
Any help that would either let me go back to 4.8.8 minGW or a simple straight forward way using Qt creator with VS2010 would be appreciated, thanks.
I think I solved parts of my own issue (at least enough to answer this problem).
1: Download and install latest minGW installer and add ';C:\MinGW\bin' to the system variable 'path'.
2: Download the Qt 4.8.4 and install it (Does not come with Qt Creator) and add'C:\Qt\4.8.4\bin' to the system variable 'path'.
3: Download the latest Qt Creator, launch it and go:
tools -> options -> build & run
From there choose the correct Qt version by pointing to the Qmake in the Bin folder (C:\Qt\4.8.4\bin in this case)
Also make sure it auto detects minGW compiler, if it does not show up I am not sure what to do.
4: If you are including a project from other Qt versions you might have to delete the users.pro file (not the .pro file) to get it to compile properly.
Last issue is that I do not have any debugger, but the program compiles in the /release folder (if you put CONFIG += release in the pro file) and I can run it by using the .exe.
Using MSVS 2010 as the compiler isn't too hard.
Download Visual Studio Express 2010.
Install it, and now you have MSVS 2010 compiler available.
The compiler should be located under C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin or somewhere similar at cl.exe.
Setting up the latest version of Qt built against MSVC 2010, with the latest Qt Creator isn't too bad, either. In Tools > Options > Build and Run > Kits, find your Qt qmake installation, and in Tools > Options > Build and Run > Compiler, find your compiler.
Now you can use the amazing Qt 5 instead of sticking in the past with 4.8 (even though Qt 4.8 is awesome and works really well, too).
Hope that helps.