I'm creating a Visual Studio Extension. This is a VSIX project.
I've added a reference to the project which I installed using NuGet.
At runtime, however, an error message is thrown. Cannot find file.... [name of dll].
What I would like to do is try and manually install this dll to the reference path that Visual Studio uses, so that it can resolve correctly.
Looks like your problem is very similar to this
But also there is a solution what we are using in our extensions.
You can create your own installer and move all necessary files into your specific folder. For this behavior you need to specify full path to your main integration dll in pkgdef
"CodeBase"="C:\Program Files (x86)\CompanyName\ProductName\integration.dll"
and vsixmanifest
<Asset Type="Microsoft.VisualStudio.MefComponent" Path="C:\Program Files (x86)\CompanyName\ProductName\integration.dll" />
files.
For VS2019 Community pkgdef and vsixmanifest should be placed here c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\Extensions\
Subscribe on AppDomain.CurrentDomain.AssemblyResolve. Wait when specific assembly with specific version! required - and load it from your folder (C:\Program Files (x86)\CompanyName\ProductName).
Related
How can the entry
<MsTestExePath>$(MSBuildProgramFiles32)Microsoft Visual Studio 14.0\Common7\IDE\mstest.exe</MsTestExePath>
in a .proj file be generalised, such that the build works for different licenses of Visual Studio 2019 as well, where mstest.exe is located at
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\Common7\IDE\MSTest.exe
in the case of an enterprise license?
The most generic solution may be to replace the variable parts of the path with msbuild macros, but which ones would that be?
According to this documentation,
The macro
$(VSInstallDir)
returns the path to the installation folder of the Visual Studio version currently used.
The following entry should therefore work for all versions of visual studio, for which mstest.exe is located in the subfolder \Common7\IDE\ under the installation directory:
<MsTestExePath>$(VSInstallDir)Common7\IDE\mstest.exe</MsTestExePath>
I am seeing some weird behavior with the latest 15.8.2 Visual Studio 2017 Build Tools. After installing the tools and ensuring that it has installed all workloads and components, I attempted to build our master solution from a batch file with the following command:
msbuild %~dp0\..\..\Master.sln /verbosity:quiet /ds /p:Configuration=Debug;Platform=x64 /m /fl1 /fl2 /fl3 /flp1:LogFile="%~dp0\MSBuild.log";Verbosity=normal /flp2:LogFile="%~dp0\ProjectWarnings.log";WarningsOnly /flp3:LogFile="%~dp0\ProjectErrors.log";ErrorsOnly
One of the very first projects fails with the following error:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\TextTemplating\Microsoft.TextTemplating.targets(340,5): error : System.IO.FileNotFoundException: Could not find a part of the path 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140\Microsoft.SqlServer.TransactSql.ScriptDom.dll'.
If you'll notice, the path that can't be found is looking for the "Enterprise" directory, which obviously doesn't exist because we installed the Build Tools. The .dll in question is there in the correct directory, just under the "BuildTools" folder and not "Enterprise". In the project itself, we have this line for the above .dll:
<HintPath>$(VSInstallDir)\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140\Microsoft.SqlServer.TransactSql.ScriptDom.dll</HintPath>
When looking at a developer command prompt on the system with just the Build Tools installed, running set, the variable VSInstallDir maps correctly to the BuildTools folder:
VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\
My question is this: where in the world is MSBuild getting the "Enterprise" directory from? We are not referencing it in ANY project, instead using $(VSInstallDir) when necessary. I have grepped the entire BuildTools directory for references to "Enterprise" and I'm finding nothing in .targets files or .props (or really any other files) that would indicate the variable would resolve to "Enterprise" rather than "BuildTools".
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.target
error MSB3147: Could not find required file 'setup.bin' in ... folder
I have seen there are similar messages during the time frame of last upgrade of VS for 2012.
I did not find the registry keys on the build server as mentioned in other posts i.e. Could not find required file 'setup.bin'
I appreciate your help.
Teamcity: error MSB3147: Could not find required file 'setup.bin'
According to this blog entry the bootstrapper files are installed during the .NET Framework SDK/Visual Studio IDE install. It also shows the registry entries that are searched to look for the bootstrapper directory.
If one computer that does not have .Net Framework SDK/Visual Studio IDE installed(such as, build server), none of the registry key would be set.
I did not find the registry keys on the build server as mentioned.
You can install .Net Framework SDK/Visual Studio IDE on the build server to get this registry key. If you don not want to install them, you could manually set it up by following steps:
Copy the whole C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK folder from the local machine with Visual Studio IDE installed to the server.
creating the 14.0 registry key and adding the value:
For 86bits:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\14.0]
"Path"="C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper"
For 64 bits:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\14.0]
"Path"="C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper"
Note: Visual Studio must be restarted.
I don't have SDK installed on the server. I have updated the .csproj with
<PropertyGroup>
...
<BootstrapperEnabled>false</BootstrapperEnabled>
</PropertyGroup>
That fixed the build.
I'm trying to set up a build process in Visual Studio Team Services, and I've done so by following the steps for UWP projects using an agent on my box, but I keep getting the following build errors:
C:\Program Files (x86)\MSBuild\Microsoft\WindowsXaml\v12.0\Microsoft.Windows.UI.Xaml.CSharp.targets(7,3): Error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\WindowsXaml\v12.0\10.0.10240.0\Microsoft.Windows.UI.Xaml.CSharp.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I checked out the path the build is complaining about and the problem is in the 10.0.10240.0 in the path:
C:\Program Files (x86)\MSBuild\Microsoft\WindowsXaml\v12.0\10.0.10240.0\Microsoft.Windows.UI.Xaml.CSharp.targets
The target file is located in
C:\Program Files (x86)\MSBuild\Microsoft\WindowsXaml\v12.0\Microsoft.Windows.UI.Xaml.CSharp.targets
Here is how the declaration in the project file looks like (I don't think it is erroneous and I don't see where this weird 10.0.10240.0 version comes from in the path):
<Import Project="$(MSBuildExtensionsPath)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets" />
Any suggestions on what could be wrong and how can I fix that?
The Universal Windows Platform was introduced in Windows 10. Visual Studio has support for UWP apps as of Visual Studio 2015. You need to use VS2015 to create a UWP project, and install VS2015 on your build agent machine.
I have a VS 2012 web project /sln that I am trying to build in TeamCity. it uses .NET 4.5 which is installed on TeamCity.
The TeamCity server has VS 2010 installed only.
I get this error when the build runs:
C:\BuildAgent\work\d5bc4e1b8005d077\CUSAAdmin.Web\CUSAAdmin.Web.csproj(799, 3):
error MSB4019:
The imported project
"C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. Project CUSAAdmin.Web\CUSAAdmin.Web.csproj failed.
Project CUSAAdmin.sln failed.
It is trying to use Visual Studio 2012 (v11.0) to build.
I have set the VisualStudioVersion to be 10 in the build.xml though??
<Target Name="BuildPackage">
<MSBuild Projects="CUSAAdmin.sln" ContinueOnError="false"
Targets="Rebuild"
Properties="Configuration=$(Configuration); VisualStudioVersion=10.0" />
As well inside the project it is defaulting to VS2010
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath
Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
Actually, you don't need to install Visual Studio on your CI server. You only need to copy a few folders from a development machine to the same location on the CI server.
VS 2015:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications
VS 2013:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications
VS 2012:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications
VS 2010:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications
.NET 4.6:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6
.NET 4.5.2:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2
.NET 4.5.1:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1
.NET 4.5:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5
.NET 4.0.1:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0.1
.NET 4.0:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0
Or, as Matt suggested, you could copy them into a subdirectory of your project and alter the <MSBuildExtensionsPath32> location in your MSBuild (typically .csproj or .vbproj) file.
Once you have done this, your project will compile. You should still set the VisualStudioVersion explicitly to the one you are using just to be sure it is set right.
NOTE: This solution works for all project types (including web projects). For a web site (that has no project file), I ended up installing the Windows SDK matching the .NET SDK version I am using, because there were missing registry keys that were causing it not to build.
Turns out it's really simple. To make MSBuild run VS2010 as the builder on a solution made by VS2012 in TeamCity, simply set the environment variable for the build configuration like this:
Name: env.VisualStudioVersion
Value: 10.0
Note TeamCity does not need VS2012 installed.
Alternatively, you can copy the build targets you need from the c:\Program Files (x86)\MSBuild to a subdirectory of your project (for example .\Build) making sure to preserve structure and add the following to your csproj:
<!-- redirect msbuild path so targets can be added to source control -->
<PropertyGroup>
<MSBuildExtensionsPath32>..\Build\</MSBuildExtensionsPath32>
</PropertyGroup>
For example, if my project root is C:\Dev\MyProjSln\MyProj
Create Folder C:\Dev\MyProjSln\Build\Microsoft\VisualStudio\version\WebApplications\
Copy Contents of C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\version>\WebApplications\ to created folder
Add MSBuildExtensionsPath32 element to Property Group under Project node in csproj
Profit!
Personally, I prefer this method of tracking build target dependencies, as it prevents build server from being dependent on having undocumented folder structure requirements, and gets your dependencies into source control
As described here:
Install nuget MSBuild.Microsoft.VisualStudio.Web.targets
Edit the .csproj file
Replace:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
with:
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />
Obviously you have to make sure versions match your case both on the nuget installed and path in <Import>
I totally disagree with changing the project files because that might affect other developers. This is what worked for me since the v11.0 folder was missing on MS build folder:
1)Create v111.
Create v11.0 folder on C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio
Copy Web and WebApplications folders from my development box "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0"
Booom! work like a charm\
Note: I installed "Microsoft Visual Studio 2012 Shell (Isolated) Redistributable Package"
Firstly, TeamCity does not require presence of Visual Studio of any version to build. When a build step in the project is configured with MSBuild runner TeamCity needs to know which version of MSBuild to use. This is a setting of a build step. Proper MSBuild version must be selected in a build step configuration according to the .NET tools installed on a build machine. TeamCity will use that value to determine the location path and will set an environment variable when invokes MSBuild.
The problem with the Visual Studio 2012/2013 is that it's only supported by TeamCity starting 8.1.0. So if your TeamCity version is before 8.1. you need to upgrade to the latest 8.1.x to see a setting for MSBuild Tools 2013. Once you select a proper MSBuild version in the build step settings the problem will disappear. For more information read here: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html