I have F# project which I want to build with command line (to use that later in FAKE config).
The problem is that MSBuild fails to resolve assembly dependencies when I use it on the project file directly. While it goes fine when I use solution file with this single project included.
I really have run out of ideas. The solution file seems to not contain any critical information.
Another weird thing is that VSCode also fails to resolve one of those assemblies. I hope that when I fix MSBuild config I may be will able to see what's wrong with VSCode.
Command line:
"C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe" FSharpWeb1\FSharpWeb1.fsproj /t:rebuild
Error message:
C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\FSharpWeb1.fsproj(173,5): error MSB4062: The "MSBuild.ExtensionPack.FileSystem.File" task could not be loaded from the assembly C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll. Could not load file or assembly 'file:///C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll' or one of its dependencies. The filename, directory name, or volume label syntax is incorrect. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.Done Building Project "C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\FSharpWeb1.fsproj" (rebuild target(s)) -- FAILED.
I've pushed the minimal demo to github: https://github.com/alehro/testMSBuild.git
It's actually easy to reproduce independently. In VS 2015 Community edition create new project from F# Web Template named "Web Api 2.2" and then try to build it with MSBuild.
Another disturbing thing is that the minimal demo produces different errors from those I've seen yesterday. Also vscode complains on different items. If yesterday it could not resolve a couple of calls, now it complains on all of:
open System.Net.Http
open System.Web
open System.Web.Http
open System.Web.Routing
telling that neither of them is defined.
Reformatting my comments to a response now that it's verified it works:
Your FSharpWeb1.fsproj references MSBuild.ExtensionPack.FileSystem.File task from MSBuild.Extension.Pack, but the path specified in the <UsingTask> tag contains $(SolutionDir) property which is not defined when you run MSBuild outside of Visual Studio.
The error message you're getting shows that in the highlighted part of the path:
The "MSBuild.ExtensionPack.FileSystem.File" task could not be loaded from the assembly C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll.
This can be remedied by conditionally setting the relative path when the property is not set by VS:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
(original response for this solution: https://stackoverflow.com/a/33782131/1659828)
One more thing I mentioned in the comments is that this solution assumes you already have the necessary dependencies downloaded in the packages folder. Visual Studio does that automatically by restoring NuGet packages before build, but when you build in another context, you have to make sure the packages are restored, otherwise the build will keep failing.
Related
My build fails with
Could not find a part of the path 'App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf'.
The file exists in in the file system
The file exists in Source Control
The get sources phase seems to find the file fine
2017-11-28T10:49:32.5448880Z Getting aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf (no errors here)
Things I've tried:
Excluding the file from the project
Deleting the file in visual studio and checking in
Deleting the file in Source Control Explorer and Checking in
Setting the file to copy if newer
Setting the file to copy always
Unticking build in configuration manager for the offending project
The error always comes back.
Copying App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf to obj\Release\Package\PackageTmp\App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf.
2017-11-28T10:50:48.4423213Z ##[error]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.targets(2603,5): Error : Copying file App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf to obj\Release\Package\PackageTmp\App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf failed. Could not find a part of the path 'App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf'.
My final act of sheer desperation was to remove the entire project so at least the rest of the solution would build, but to my utter surprise the error still remains.
The solution was to set the file to do not copy and clear the MSBuild Arguments in the build definition.
How to create build definition for multiple solutions that have dependency?
Background here:
There are two solutions
Solution A is class library contains an object class 'ClassA'
Solution B is console program that use 'ClassA' by add dll reference generated by solution A.
I would like to server build both solutions using one TFS 2017 build definition.
It raise out error:
Main\Source\SolutionB\Program.cs (13, 13)
Main\Source\SolutionB\SolutionB\Program.cs(13,13): Error CS0246:
The type or namespace name 'SolutionA' could not be found (are you
missing a using directive or an assembly reference?)
How to config the build definition that SolutionB would know to use the dll generated from the build of SolutionA?
You should build your first project that will be used at second project as dll and than copy files to build artifacts; than publish your dlls to specific folder that you referenced in your second project and finally build your second project.
You can check this image that with similiar process, just in below image it is publishing artifacts to three diffrent location, in your case it should be one publish task.
This is one of the simple way; but if you use the project A for some other projects too you may want to use NuGet packages. I am going to describe this as solution 2.
Solution 2: You should create a Nuget packages by the artifacts of Project A. You can host your Nuget packages in custom source folder. Add your first project's package to your project as a reference. You don't need to do something extra just add a nuget restore task to your build definition. If you want, you can publish your first project as a nuget package during the build definiton. Please check how to restore and install neuget packages by build definiton.
I'm trying to build a BizTalk application through Jenkins and encountering a weird error. I was able to build the .btdfproj successfully a few days ago. Nothing was changed in the setup project or the server. I can see the Microsoft.Sdc.Tasks.dll in the location as well.
I'm not sure what is the issue is here. Any ideas?
error MSB4062: The
"Microsoft.Sdc.Tasks.BizTalk2006.Application.Delete" task could not be
loaded from the assembly C:\Program Files
(x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\Microsoft.Sdc.Tasks.BizTalk.dll.
Could not load file or assembly 'file:///C:\Program Files
(x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\Microsoft.Sdc.Tasks.BizTalk.dll'
or one of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly
and all its dependencies are available, and that the task contains a
public class that implements Microsoft.Build.Framework.ITask.
Okay, that was a silly mistake. Someone moved the jenkins job, one folder up and one step in the job's configuration had the older path hardcoded. I undid the move and it started building successfully. The error was totally misleading though.
I'm trying to configure an automated build of a project that has a NuGet package reference, but I'm not having any luck. (FYI I'm still pretty wet behind the ears with all of this, so please provide simple steps and/or configurations.)
Note: this isn't a duplicate of other similar questions, as I'm using a central package repository. Other similar questions make no mention of this important detail, so they should be assumed to not be relevant.
The build runs fine without the reference. I added Newtonsoft.Json and bound to it by including this simple construct:
Dim eHandling As Newtonsoft.Json.ConstructorHandling
eHandling = Newtonsoft.Json.ConstructorHandling.Default
I checked it in and the build started, but NuGet hadn't first copied the assembly to my application's bin folder. It did, however, copy it to here:
Restoring NuGet package Newtonsoft.Json.9.0.1.
Adding package 'Newtonsoft.Json.9.0.1' to folder 'C:\Agent\_work\1\s\packages'
Naturally the build failed, as it couldn't find the dependency.
It's worth noting that I'm using a central package repository on my dev machine:
<config>
<add key="repositoryPath" value="D:\Dev\Packages" />
</config>
I'd like to emulate this behavior on the server as well, e.g. C:\Packages\*\*.nupkg.
I tried using the standard %AppData%\NuGet\NuGet.config file, but the build ignores it. I tried the advice in this answer (using repositoryPath instead of packageSources as shown there), but that causes the server to hang until I restart the VSO Agent service. Thinking it might be a permissions issue, I reconfigured the agent to run under the user account associated with the %AppData% location of NuGet.config. Still no luck. No build.
How can I get NuGet to download and populate the central package repository on the server and then copy the appropriate dependencies to the application bin folder prior to running the build step?
EDIT 1
Update: Apparently something's working, as I now have a C:\Packages\Newtonsoft.Json.9.0.1 folder on the server. However, the assembly still isn't being copied to the application bin folder prior to build. Same result. Failed build.
EDIT 2
OK, I'm getting closer. I created a D: drive on the server and set the local repositoryPath value to D:\Dev\Packages, the same as it is on my dev machine. The build is still failing, but a quick look at the project XML reveals this:
<Reference Include="Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\..\..\Packages\Newtonsoft.Json.9.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
<Private>True</Private>
</Reference>
How to deal with that relative path? That should fix it, yes?
EDIT 3
OK, that worked. I edited the project and changed HintPath to
D:\Dev\Packages\Newtonsoft.Json.9.0.1\lib\net45\Newtonsoft.Json.dll
I now have a successful build.
But this is going to get real tedious real fast. Surely I'm not going to have to do this for every single NuGet reference in every single project, past present and future... am I?
OK, got it.
As long as the repositoryPath folder on the server is the same number of levels deep as on our dev machine—in relation to the folder in which the Build Agent puts the project file—we can put it anywhere we want and retain the relative HintPath value in the project file.
For example, in my case I ended up setting the server location to C:\Agent\Build\Packages, to match the hierarchical location of the local Git repos on my dev machine:
D:\Dev\Packages
D:\Dev\Git\app.repo\App\App.vbproj
Works great.
EDIT
Just to clarify, the action of copying the assembly from the package folder to the application bin folder isn't a NuGet action. It's an MsBuild action (i.e. the CopyLocal setting in the project's assembly reference properties).
The reason it was failing was that MsBuild couldn't find the assembly to copy, according to its relative reference as specified in the project file.
So technically my question title is incorrect. The NuGet Installer step has been working fine all along.
I have TFS 2010 and for one of the team project I have created the build definition (used default build template) and added the solution of one of the project. But when try to create build getting the following error:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
(902): The command "if Debug == Debug copy
"C:\Builds\14\\\Sources\ServerObjects..\SharedInterfaces\bin\debug*.dll"
"C:\Builds\14\\\Sources\ServerObjects..\ServerObjects\bin\debug"" exited with
code 1.
I think you maybe has wrong folder structure on the source control, see my answer on similar question here
teambuilding and deploying a dll (e.g. wpftoolkit.extended.dll)
TeamBuild overrides the output folder so the bin\debug (or bin\release) folder won't exist. It collates the output into Binaries.
For your custom build step use the obj folder instead of bin as that'll be the same under both TeamBuild and the local machine build.