We have been using Visual studio 2010 - 2013 on the build server using the following MSBuild command so far:
Set msBuilder=%windir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
However recently we moved to VS 2015, and had to uninstall all other VS versions (for saving space), and used the following build location (partially also to cater compilation of C# 6.0 features):
Set msBuilder =%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe
This seems to work for most of the VS Solutions we have,however for one particular VS solution, when we execute this line:
Set doSolutionBuild=%msBuilder% MySolution.sln /t:clean;Build /p:Configuration=Release;Architecture=x86;Platform=x86 /v:n
it opens and instance of VS 2015 of the same project on the build server and the build process just hangs there in the command prompt.
Can anyone explain how we could resolve this?
Related
When trying to create a 64 bit MSIX package using the Publish command in a VS 2019 WPF packaging project,
we are getting the following error 'wappublish\win-x64\project.assets.json' not found... Run a NuGet package restore to generate this file'.
The packaging project itself builds fine and can be debugged. Running 'dotnet restore' from the package manager console does not help. We have noticed there is no win-x64 directory created under wappublish.
We are using VS 2019 16.7.4 Community Edition. Anyone any ideas what could cause this.
Thanks
We are slowly migrating to VS2017 and most of the project do that silently without much interference. Today started migrating a WPF project from VS2015 to VS2017. When I build the solution I get the following warning:
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
I googled the problem but I seem to be alone out there. I have no clue what could cause this. The .Net target is 4.5.1 but changing that to 4.6.2 make no difference. Neither does clean or remove bin and obj directories. Who has got a clue?
I encountered this problem while building from the command line after migrating from VS2017 to VS2019 for a solution containing class libraries. I found I had VS2017's version of MSBuild in my PATH environment variable - C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin. Removing that path from the environment variable and re-opening my console solved the issue.
VS2017 MSBuild autodetection takes MSBuild/v14 instead of v15 for WPF project
You can try to update the version of nuget.exe to the 4.0 and above in the .nuget folder.
Visual Studio 2017 comes with NuGet 4.0 and NuGet 4.0 Package Manager Extension is currently not available for Visual Studio 2015 (Visual Studio 2015 comes with NuGet 3.4.4, and NuGet 3.5.0 is available as an explicit download for Visual Studio 2015 as well).
According to your comment, it seems the old nuget.exe not detect the MSBuild version 15.0, so please try to update the nuget.exe to 4.0 and above in the .nuegt folder.
Besides, I found your solution that is still configured by old package restore method "MSBuild-integrated restore", which is the original Package Restore implementation and though it continues to work in many scenarios, it does not cover the full set of scenarios addressed by the other two approaches.
Automatic Package Restore is the NuGet team's recommended approach to Package Restore within Visual Studio. You can convert to use the automatic package restore. Check the following thread for details:
Nuget: Switching from "Enable Package Restore" to "Automatic Package Restore"
Hope this helps.
I recently have attempted to migrate a solution created and developed in Visual Studio (VS) 2012 to VS 2017.
I've managed to migrate all projects of my solution except for a Report Server Project. When I try to open my solution in VS 2017 I get the following message:
I click on Yes and VS automatically upgrades the project file (this is a file having the extension .rptproj)
When I now try to build the project I get the following error message:
Error Copying file Reports\Report\Project1\MyReportProject.rptproj.user to
obj\Debug\AspnetCompileMerge\Source\Reports\Report
Project1\MyReportProject.rptproj.user failed. Could not find file
'Reports\Report Project1\MyReportProject.rptproj.user'
I thought the upgrade would be performed transparently. Am I missing something? Is there any extra step I should take in order to do the upgrade?
Note: I've already downloaded and installed the latest version of Microsoft Reporting Services Projects .vsix package.
You can try the latest msbuild.exe for SSRS is here.
This includes steps of up-gradation of SSRS for both VS15 and VS17.
Once you install the latest update, depending on which version of Visual Studio you’re using, the new files enabling MSBuild for your projects will be installed in different folder path:
In Visual Studio 2017, it’ll will be a nested folder in your Visual Studio folder hierarchy. For example, the location with the Community Edition is in the Community folder:
Edit 1:
Try these steps:
1) Close Visual Studio - 17
2) Open VS-17 Installer
3) Try to install the SSDT workflow as:
I am using VS 2013 and need to reference the Lync 2013 SDK. The install fails with:
Microsoft Visual Studio 2010 SP1 or higher not found
Is there any work around or do I have to downgrade to VS 2012?
Thanks,
Bill
I got it solved.
You can fix it by installing WinRAR and then right-clicking the .EXE file (the installer), extract it, and then run the 64 bit setup file. It installs to Program Files from where you can just reference the DLLs.
The Publish feature stopped working once I installed Visual Studio 2012. Publish cannot find the prerequisite Microsoft .Net Framework 4 Client Profile (x86 and x64). Previously in Visual Studio 2010 this worked fine. I use 64-bit Windows 7.
The exact Visual Studio 2012 error message reads:
Error 104 - To enable 'Download prerequisites from the same location
as my application' in the Prerequisites dialog box, you must download file
'DotNetFX40Client\dotNetFx40_Client_x86_x64.exe' for item 'Microsoft .NET
Framework 4 Client Profile (x86 and x64)' to your local machine. For more
information, see http://go.microsoft.com/fwlink/?LinkId=239883
I placed the file dotNetFx40_Client_setup.exe in the location:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages\DotNetFX40Client
I also left it in it's original location (note the v7.0A):
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client
Edit (after solving the problem): I see that the correct setup file (dotNetFx40_Client_x86_x64.exe) is actually in the v7.0A folder. Had I just copied it from there everything would have worked (rather than downloading the wrong setup).
Publish works fine when I change the option "Download prerequisites from the same location as my application" to "Download prerequisites from the component vendor's website" (at project Properties -> Publish -> Prerequisites...)
I noticed a yellow exclamation point beside the (checked) "Windows Installer 3.1" with the warning: "Prerequisite could not be found for bootstrapping". For that I have the file WindowsInstaller-KB893803-v2-x86.exe in the folder:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\WindowsInstaller3_1
The application has run fine within my company's network for the past year when published with Visual Studio 2010. I opened the solution file in VS 2012 (for the first time) and it compiles and runs fine locally. Only the Publish feature is broken.
Am I missing something? Where is ClickOnce Publish expecting to find these prerequisites for my WPF application?
I'm answering my own question. The problem went away when I used a different .Net 4 Client setup program. The exe that works for me is dotNetFx40_Client_x86_x64.exe found at:
http://www.microsoft.com/en-us/download/details.aspx?id=24872
The wrong setup program is dotNetFx40_Client_setup.exe which I was led to by following the Microsoft MSDN help topic How to: Include Prerequisites with a ClickOnce Application (Visual Studio 2012) which led me to this link to the setup. I use Chrome which downloaded the web installer which I didn't realize was not the file I needed. Had I been using IE none of this would have happened. I was clued into the problem by this StackOverflow question which suggests renaming the setup program. Instead of renaming it I just downloaded the correct one.
re: Windows installer: VS2012 doesn't include the same prerequisites as VS2010, but you can copy the package from the previous SDK folders to the new one, and it will magically show up in the prerequisite list in VS2012 and work!