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:
Related
Need your help
I have successfully installed VS2017 on my computer .
But when I tried to install SQL server data tools 15.6.0 or 15.5.1 it gives me error as below :
Setup failed
The configuration registry key could not be opened(0x800703F3)
Thanks All!!
The latest version (15.6) of SSDT is incompatible with the latest version (15.7) of Visual Studio 2017. You currently have two choices:
Wait for an updated version of SSDT or VS2017 to be released, or
Completely uninstall VS2017 and install an older version.
If you want to go with option 2, do the following:
Run this command: C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\layout\InstallCleanup.exe -f
Download and install version 15.6.7 of Visual Studio (link to the Community edition)
Download and install SSDT 15.6.0
This info was taken from a post on the Visual Studio Developer Community forum.
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'm attempting to build a .sqlproj on a TFS Build Server. I've followed the instructions here:
http://sqlproj.com/index.php/2012/03/headless-msbuild-support-for-ssdt-sqlproj-projects/
which I was directed to from here:
How to build .sqlproj projects on a build server?
But I still cannot build. The error is:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets
(441): The "SqlModelResolutionTask" task could not be instantiated
from "C:\Program Files
(x86)\Common7\IDE\Extensions\Microsoft\SQLDB\Dac\120\Microsoft.Data.Tools.Schema.Tasks.Sql.11.dll".
System.TypeInitializationException: The type initializer for
'Microsoft.Data.Tools.Schema.Tasks.Sql.DataTask' threw an exception.
---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Data.Tools.Schema.Sql, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified. at
Microsoft.Data.Tools.Schema.Sql.Extensibility.ToolingShim.ConfigureExtensions()
--- End of inner exception stack trace --- at Microsoft.Data.Tools.Schema.Tasks.Sql.DataTask..ctor()
The SqlTasks.targets file, used by the SQL project, references this:
C:\Program Files (x86)\Common7\IDE\Extensions\Microsoft\SQLDB\Dac\120\Microsoft.Data.Tools.Schema.Tasks.Sql.11.dll
which in turn references the invalid version mentioned above.
However, the files installed by the process in the link above don't install this version. They do install version 10.3.0.0, which is referenced by
C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\Microsoft.Data.Tools.Schema.Tasks.Sql.12.dll
but this file is not the one used by the .targets file.
I don't know what the numbers at the end of this dll mean, but it seems odd to me that the one ending 12.dll references an earlier version of the one ending 11.dll.
I'm using Visual Studio 2013 and SQL Server 2012 - neither of which are installed on the build server, which I believe is the recommended situation. I don't know what the IDE folder is, or why the .targets file is using it.
I've spent about two days now trying to get this to build, but I'm out of ideas. Anyone know what's going on?
If you are running VS2013 SSDT is built into VS as long as you select it on the install screen. Install VS2013 with SSDT onto your build server. create a build definition and under Process > Build > Advanced Add the following to the MSBuild arguments to build the sql proj
/t:Build
if you have a publish profile and want to test publishing to SQL then add the publish switch and provide the link to the profile file
/t:Publish /p:SqlPublishProfilePath=MyDB.publish.xml.
this will publish the db to the server specified in the publish file.
the publish profile file can be created by opening the project in Visual Studio, right click on the project and select publish. Select save once you are happy with the publish options and then check in the file to source control so the build can find it, (project Root).
I was having this issue building a SQL Server project on an Azure DevOps CI/CD pipeline. None of the pre-built build tasks would work for me. And it is not possible to install a VS instance on the build server, I guess.
I solved this by avoiding to add a SQL Server project to the solution.
I achieved this by using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from the set of SQL scripts. By adding this second project to the solution, I managed to continue taking advantage of linking the project to a live database through SQL Server Object Explorer on Visual Studio. I gave a more detailed explanation in this answer.
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!