I am new to TFS build. I am using TFS Visual Studio Template.
My app uses dev express dlls.
All my devexpress dlls are checked into Common Folder:
When I run the build, build agent is failing with unable to find dev express component. Its looking for dlls under : C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1
2017-05-23T19:15:04.0271172Z For SearchPath "{TargetFrameworkDirectory}".
2017-05-23T19:15:04.0271172Z Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\DevExpress.Charts.v15.2.Core.winmd", but it didn't exist.
2017-05-23T19:15:04.0271172Z Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\DevExpress.Charts.v15.2.Core.dll", but it didn't exist.
2017-05-23T19:15:04.0271172Z Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\DevExpress.Charts.v15.2.Core.exe", but it didn't exist.
2017-05-23T19:15:04.0427439Z Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\DevExpress.Charts.v15.2.Core.winmd", but it didn't exist.
2017-05-23T19:15:04.0427439Z Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\DevExpress.Charts.v15.2.Core.dll", but it didn't exist.
2017-05-23T19:15:04.0427439Z Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\DevExpress.Charts.v15.2.Core.exe", but it didn't exist.
2017-05-23T19:15:03.7771166Z 7>ResolveAssemblyReferences:
2017-05-23T19:15:04.0271172Z Primary reference "DevExpress.Charts.v15.2.Core, Version=15.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a".
2017-05-23T19:15:04.0271172Z ##[warning]C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "DevExpress.Charts.v15.2.Core, Version=15.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
2017-05-23T19:15:04.0271172Z 7>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "DevExpress.Charts.v15.2.Core, Version=15.2.5.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [E:\agent\CentralCompliance\_work\9\s\CentralCompliance\CentralCompliance.csproj]
2017-05-23T19:15:04.0271172Z For SearchPath "{CandidateAssemblyFiles}".
Any idea why its not looking into the common folder? What am I doing wrong?
Thanks for help.
Due to the VS designer specificity, all designer assemblies should be installed in the GAC. Guess this is why it's looking for dlls under:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1 instead of your common folder. It's not possible to deploy those assemblies to computers without DevExpress installation. So does the build agent. The design assemblies which will be put into the GAC during the DevExpress installation.
Besides to avoid the license issue, you should also need to install the DevExpress on build agent.
We are verifying and integrating the license information at the
"building an application" stage. So, it's necessary to have our
components installed and registered on a machine. Otherwise, the
trial window may appear. You can organize a build server and build
projects there. The build server should have the components
installed as well, however, you can be sure that you will not get a
licensing issue.
More details please take a look at below link：
Is it possible to keep DevExpress dlls in TFS
Add DevExpress libraries to TFS source control
You have to install DevExpress on your build agent. The build process restores the dependencies by using a local DevExpress installation.
Related
I don't recall the previous version I had (it could have been 16.8.1), but updating just now to 16.8.4 results in none of my solution projects being able to load. Here's the output window for one of my solutions:
F:\Users\username\Documents\Visual Studio Projects\FitnessManagerCore\FitnessManagerCore\FitnessManagerCore.csproj : error : The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\Microsoft.CSharp.Core.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\Microsoft.CSharp.Core.targets" is correct, and that the file exists on disk. C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.CSharp.CurrentVersion.targets
F:\Users\username\Documents\Visual Studio Projects\GeneralUtilities\GeneralUtilities\GeneralUtilities.csproj : error : The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\Microsoft.CSharp.Core.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\Microsoft.CSharp.Core.targets" is correct, and that the file exists on disk. C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.CSharp.CurrentVersion.targets
F:\Users\username\Documents\Visual Studio Projects\FitnessManagerCore\FitnessManagerConsole\FitnessManagerConsole.csproj : error : The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\Microsoft.CSharp.Core.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\Microsoft.CSharp.Core.targets" is correct, and that the file exists on disk. C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.CSharp.CurrentVersion.targets
VS advised to try to reload the projects manually. When I attempt this, I get the following error message:
It seems Microsoft has no means to roll back a previous installation. I do not have a restore point. I do not want to uninstall/reinstall.
Edit:
I just tried creating a new solution to see what would happen if I tried to load one of my existing projects. When creating a console app w/ .NET Core, I get this:
Update:
This latest VS 2019 simply does not want to work on my machine in any capacity. I uninstalled VS 2019, rebooted, and attempted to reinstall. The installation stops midway with the below error message. When I click "Report this problem", it opens a Microsoft web page to report the issue, but says "Disconnected from Visual Studio". Since I can't roll back to a previous version according to what I'm reading, I guess I just can't use VS 2019 anymore.
You could check in your csporj file if you have:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
You would need to change MSBuildToolsPath to MSBuildBinPath, like this:
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
When you create a project in Visual Studio 2008, $(MSBuildToolsPath) is added by default to your csproj file as the path to Microsoft.Build.Engine v3.5.
Be sure to change it to $(MSBuildBinPath) which is the path to Microsoft.Build.Engine v2.0.
(more info here)
After installing this version, nothing that touches F# will build, everything throws the same exception:
error FS0193: Could not load file or assembly System.Buffers, Version=4.0.3.0, blablabla..
Apparently it's nothing to do with what I'm building. Even trying to execute let x = 3 in fsi.exe has the same problem.
Anyone else had this problem?
Yes, this is a known problem, see https://github.com/dotnet/fsharp/issues/9295.
While the next fix isn't out yet, you can resolve it by manually copying the missing assemblies. The exact list of missing assemblies is mentioned in this comment. The cause was explained by Kevin Ransom to be that the Setup for MSBuild didn't get the new dependencies for fsc.exe.
Note that FSI from within Visual Studio shouldn't have this issue, nor should building from within Visual Studio 2019. The way I understand it, only the MSBuild Tools are affected.
For posterity, in case the links go dead, the workaround in the Github issue is to just copy the dlls over:
copy "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\PublicAssemblies\*.dll" "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\FSharp"
Edit: the source path given above may not always be correct, depending on what versions of VS you've installed. Alternatively, try:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\PublicAssemblies
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\PublicAssemblies
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\PublicAssemblies
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\PublicAssemblies
If you only want to copy the minimal set that's needed, just copy only these files, that's the diff set:
System.Buffers.dll
System.Memory.dll
System.Numerics.Vectors.dll
System.Reflection.Metadata.dll
System.Resources.Extensions.dll
System.Runtime.CompilerServices.Unsafe.dll
System.Threading.Tasks.Dataflow.dll
I am trying to build UWP app (targeting 16299) from command line from Jenkins setup.
The system has only VS build tools 2017.
used this command to build
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\msbuild.exe" /t:Rebuild /p:Configuration=Release;AppxBundle=Always;AppxBundlePlatforms="x86\x64\ARM" /p:BuildAppxUploadPackageForUap=true SOLUTION_FILE.sln
error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\WindowsXaml\v15.0\Microsoft.Windows.UI.Xaml.CSharp.targets" was not found. Also, tried to find "Microsoft\WindowsXaml\v15.0\Microsoft.Windows.UI.Xaml.CSharp.targets" in the fallback search path(s) for $(MSBuildExtensionsPath) - "C:\Program Files (x86)\MSBuild" . These search paths are defined in "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe.Config". Confirm that the path in the declaration is correct, and that the file exists on disk in one of the search paths.
Another issue found is nuget is not restoring any package, so updated nuget to 4.4.1 then I got the error
MSBuild auto-detection: using msbuild version '15.5.180.51428' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin'.
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
same issue with nuget 4.6.0 also
I tried by adding following in project file
<PropertyGroup>
<RestoreProjectStyle>PackageReference</RestoreProjectStyle> </PropertyGroup>
same issue with msbuild and nuget, anyone succeed in building UWP in Jenkins?
Update 05-01-2015
Followed instruction according to answer.
Copied NuGet folder
Copied the "WindowsXaml" folder.
Used MSbuild restore instead of Nuget restore to fix msbuild trying to find packages in "C:\WINDOWS\system32\config\systemprofile.nuget\packages\"
With all these changes no more issues in build,
But the appx bundle is not present. may be individual appx for x86/x64/ARM has to be created and then some kind of merging i s required.
so need further investigations
From the directory path that you have for MSBuild, I see that you may have installed MSBuildTools installer instead of the community, professional,... editions.
I tried that before and found that it's incomplete and doesn't have all dependencies for building Uwp tools, take a look at some of the comments here about the issues.
First Workaround: You can install Uwp Workload from VS Community or Professional as it has all dependencies, till Microsoft fix the issues in BuildTools installer.
Bonus: if you want to run the installer from command line, you can compose command line like that:
vs_installer.exe --installPath "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools" ^
--add Microsoft.VisualStudio.Workload.Universal ^
--add Microsoft.VisualStudio.Component.Windows10SDK.14393 ^
--add Microsoft.Component.MSBuild ^
--passive --wait --norestart
The longer workaround, I managed to install other dependencies but I believe it's kind of hassle if you are automating this installation, snippets from this article
Copy the Sdks folder from a machine that has VS2017 installed at:
c:\Program Files(x86)\Visual Studio\2017\Professional\Build MSBuild\Sdks
to your build machine at:
c:\Program Files(x86)\Visual Studio\2017\Build Tools\MSBuild\Sdks
And for the nuggets issue:
Copying the NuGet import files will do the tr Again, from a machine
with VS2017, copy the following folder: C:\Program Files
(x86)\Microsoft Visual
Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\NuGet
to your build machine at: C:\Program Files (x86)\Microsoft Visual
Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet
Note: If you come by this later and found that Microsoft fixed the issues related to Uwp in MSBuildTools installer, please leave a comment about it in this answer to update it.
I am trying to use Team Services CI Build, but it keeps on failing with the same error:
##[error]MobileClient\LoginNavigation\CommentPage.xaml.cs(1,7): Error CS0246: The type or namespace name 'Android' could not be found (are you missing a using directive or an assembly reference?)
Which seems to be right, since in a previous step it is complaining about not finding that library:
##[warning]C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "Mono.Android". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
Also, it is logged where the build is searching it:
For SearchPath "{HintPathFromItem}".
Considered "..\..\..\..\..\..\..\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v6.0\Mono.Android.dll", but it d idn't exist.For SearchPath "{TargetFrameworkDirectory}".
For SearchPath "{TargetFrameworkDirectory}".
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile259\Mono.Android.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile259\Mono.Android.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile259\Mono.Android.exe", but it didn't exist.
For SearchPath "{RawFileName}".
Considered treating "Mono.Android" as a file name, but it didn't exist.
To my understanding, this file is missing in the Team Services build server, right? How could I solve this? Should it be necessary to change this directory?
One important thing is that locally, in my machine, the Visual Studio and the command line MSBuild are working correctly.
This happens during the Visual Studio Build step, which has the following configuration:
MSBuild Configuration: MSBuild x86
Visual Studio Version: Visual Studio 2015
MSBuild Arguments: /p:DeployOnBuild=true /p:WebPublishMethod=Package
/p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.artifactstagingdirectory)\"
Visual Studio Build Solution step version: 1.*
Here are the steps of the Team Services build:
Ok so after reading the answers and suggestions I received, I got a hint of what I had to do to resolve this. Basically, I was making two mistakes:
First of all, on the project that was failing, I changed the Mono.Android reference to one inside the project's folder. Even though that error disappeared, I kept on having more and more errors related to Xamarin and Android.
So that's when I followed another suggestion in this thread: using a Xamarin.Android template. The thing is, that in this project I have a .sln file, which contains different type of projects, including a Xamarin project, a Web Api, and some Class Libraries. I was trying to build them all in the same Team Services build definition, but I realized it was much more efficient to have different definitions according to the different type of projects.
In consequence, I ended up having a build definition for the Xamarin project, using the Xamarin.Android template, and another one for a .sln file I created with all the projects used by the Web Api project. The amount of errors was reduced drastically, and I felt I wasn't "swimming against the tide" anymore.
I would suggest everyone having a solution with a wide variety of project types to do the same.
I created an ASP.NET MVC project in Visual Studio 2012 on my laptop, did a bit of work on it without issues, then checked it into source control. I've checked it out on my main desktop machine (a completely fresh Git clone), and it won't compile stating that various references are missing (one of which being entityframework.dll). Looking back on my laptop, those DLLs are in my project's "bin" folder (which I didn't add to source control for obvious reasons). On my laptop, if I rename my bin folder, then I get the same compile errors. Am I incorrect in not committing certain DLL files that are in my bin folder? Surely those DLLs should be copied into the bin directory at compile time?
The desktop probably can't find the folder to copy from.
You should add the references using NuGet (if you aren't already) and include the packages folder in source control. (or enable package restore)
You should look as to where the library references are stored in your project file. If the project is referencing copies in your bin directory then you have your project setup incorrectly.
You should maintain a libraries directory in your source control tree that id checked in like any other dependency.
The bin directory should be output only.