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.
Related
We have a C++ application using MFC. We also use the manifest that is auto-generated and we actually do use it.
The environment is windows server 2012 it has TFS 2018 installed on it and a build agent configured. Visual studio 2017 pro 15.6.2 is also installed with all the needed packages for our project.
The weird thing is when I compile the project within visual studio everything is build just fine BUT when I build with the build agent on the same machine there is an error:
Generating code
All 26621 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.Finished generating code
C:\_TFS(0,0): Error c1010070: Failed to load and parse the manifest. The system cannot find the file specified.
C:\_TFS : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified. [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
LINK(0,0): Error LNK1327: failure during running mt.exe
LINK : fatal error LNK1327: failure during running mt.exe [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
Done Building Project "C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100.sln" (default targets) -- FAILED.
Build FAILED.
"C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100.sln" (default target) (1) ->
"C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj" (default target) (4) ->(Link target) -> C:\_TFS : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified. [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
LINK : fatal error LNK1327: failure during running mt.exe [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
0 Warning(s)
2 Error(s)
Time Elapsed 00:02:11.68
Process 'msbuild.exe' exited with code '1'.
Now it says that a certain file cannot be found except that the file is actually there. My guess is that something else might be wrong here.
So I went to the folder where the sources are being placed via the get sources task which is in the agent's folder structure and I then opened the solution with visual studio and build it there and again within visual studio the build is successful.
I've been looking on the internet and I found a couple of solutions such as:
disable manifest creation in the linker options menu... (this is not a solution for us since we need it)
mt.exe can't cope with spaces in the file path (strange since when opening the same files in visual studio it does build or is there something different when opening it from VS or building it with an agent?)
Digital Guardian might restrict execution (we don't have that nor can I see it in procmon)
A virus scanner might block execution (nothing is installed on the environment)
when using the Visual studio build step instead of msbuild build step in the TFS build system the build fails with exactly the same error.
I'm pretty sure that it has nothing to do with points 3 and 4 (virus scanners/ security restrictions) since I can build it successfully within the visual studio itself.
I just started to use TFS build for the first time so there is a big chance that I'm missing something here. Hopefully, someone can help me out.
I have asked this question on MSDN forums as well (https://social.msdn.microsoft.com/Forums/en-US/587b1c42-8ac6-4deb-95aa-4d74c91fd55f/msbuild-issue-on-windows-server-2012-link1327-mtexe-error-c1010070?forum=Offtopic) where I got the suggestion to ask the question here as well.
The issue is found and we have a workaround implemented.
When an Agent is defined in a path that has spaces in it mt.exe will not be able to find a file within that path. But this gets stranger because when you have a path that contains spaces and you run msbuild.exe via the command line mt.exe will find the path and the build is successful. after some testing we found out that if you combine the execution on an agent (which is located in a path that has spaces) the execution of mt.exe by the agent will have this error that mt.exe is not able to find the file. Now to completely test this and to make 100% sure that this has something to do with the agents path I created a build definition with specific execution paths. So I disabled the get sources step, removed all the sources then placed all the sources in a space free path and then ran the msbuild commands on an agent that contains spaces in its path and then it failed again.
So what we settled for is to locate our agents in a path that does not contain any spaces and now it builds just fine.
When doing an ant build (thought jenkins) for a test project, I get the below error. As this test project will be deployed in tomcat why does the build require a netbeans specific module
Obviously I can add the jar file to a path in jenkins and then continue the build, but want to know why it needs a netbeans specific jar?
Is it because the project setup in Netbeans is wrong?
Thanks in advance.
Tony
======Error below here =========
var/lib/jenkins/workspace/DeployTest2/nbproject/build-impl.xml:797: The libs.CopyLibs.classpath property is not set up.
This property must point to
org-netbeans-modules-java-j2seproject-copylibstask.jar file which is part
of NetBeans IDE installation and is usually located at
/java/ant/extra folder.
Either open the project in the IDE and make sure CopyLibs library
exists or setup the property manually. For example like this:
ant -Dlibs.CopyLibs.classpath=a/path/to/org-netbeans-modules-java-j2seproject-copylibstask.jar
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.
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'm trying to Deploy a Jar File from an ANT script (with OjDeploy), which compiles successfully. But when I run the main project (Which has the Jar dependency), I get a huge incident, when I analysed the incident log, it says
"Caused by: java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist"
I analysed both the jar files (One generated by the ANT script and the other generated from Jdev). I couldn't find any difference b/w Manifest of those two jars. The other folders are also the same, In other words, both are almost the same, or I'm not able to figure out the difference between the two jar files generated.
I know, I'm missing something, config of build.xml or something, but not able to figure out the exact problem.
Thanks,
Shiva Shankar
My guess is that the problem is not in the JAR file but rather in the project that consumes it.
Seems like the DB connection in that project is different than the one in your JAR project - which causes one of the tables that is needed in the DB not be found.
I figured out a way to solve the problem. Not sure what was the cause of this issue, but a couple of changes made both to JAR/EAR build scripts set the things right
While building JAR files:
Uncheck "Make this the project build file" while creating the ANT build file, while the "Include Packaging Tasks (uses OjDeploy)" must be checked.
Remove "nocompile" parameter from tag in the OjDeploy.
While Building EAR files:
Create EAR in the view controller project.
Go to the View Controller Project Properties-> Project Source Path -> Resources, remove the newly created build file dependency, which specifies that the build file is for the whole project and not for the individual project.
Remove "Project" parameter from tag in the OjDeploy. (Ensures to build for the whole application)
Remove "nocompile" parameter from tag in the OjDeploy.
These are the exhaustive set of changes, which I made to ensure the ANT files are building correctly, if you get any other errors after this EAR is deployed, then its definitely due to code, EO/VO or DB related.
Thanks for all the help!!
Shiva Shankar