It seems that MsBuild versions 14 does not generate the licenses.licx file when used "manually". When we compile our code from visual studio (v2017), everything works fine, but when done manually, from a batch file, the license file is not generated, and clearly our build fails, because the file is not found.
We use the following command:
msbuild.exe [project_path] /verbosity:normal /t:rebuild /tv:14.0 /p:Configuration=Release,Optimize=true,Platform=AnyCPU,OutputType=Library
I tried every solution on the internet, I've installed .net SDK for windows 7, 8 and 10, and still no luck.
Does anybody have an idea why?
Thank you in advance
UPDATE:
My description was not totally correct. The thing is msbuild does not output the [assembly_name].dll.licenses file. The licenses.licx exists under the "My project.." correctly.
We found that vs 2017 has MsBuild version 15 installed under "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\msbuild.exe" and not under "C:\Program Files (x86)\MSBuild\15.0\bin" like the previous version 14.
By using the version 15, the issue no longer occurs.
Related
I am setting up a new TeamCity build agent. Several build configurations that run perfectly well on the existing agent are failing on the new agent, with errors like this (whitespace added for clarity):
[22:14:32][someproject.vbproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Microsoft.VisualBasic.CurrentVersion.targets(322, 5):
error MSB4019: The imported project
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Roslyn\Microsoft.VisualBasic.Core.targets"
was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Note the path on line three after "The imported project". The error is correct; the folder does exist but the file does not exist there. However the Microsoft.VisualBasic.Core.targets file does exist at a slightly different path
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Roslyn\Microsoft.VisualBasic.Core.targets
Is there an easy fix for this, perhaps a registry entry telling MSBuild where to look?
Cause
On your machine, there are two copies of VS 2017 installed, Professional edition and the raw Build Tools.
You didn't install VB bits for Professional, while did that for Build Tools.
TeamCity prefers MSBuild from Professional edition.
Combine all above, the issue happened.
Fix
You should either force TeamCity to use MSBuild from Build Tools, or add VB to your VS Pro installation.
Reference
https://blog.lextudio.com/the-rough-history-of-msbuild-cc72a217fa98
So, we were using 2013 TFS dlls in our projects (namely TeamFoundation.Client, TeamFoundation.VersionControl.Client, and TeamFoundation.Common). I recently upgraded the project to use 2017 versions of the above mentioned dlls (We have VS2017). I am getting them from the below folder.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer
After upgrading, when I build my solution, I get the following error:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\Microsoft.NET.Build.Extensions.NETFramework.targets(56,5): warning : Resolved file has a bad image, no metadata, or is otherwise inaccessible. The system cannot find the path specified. (Exception from HRESULT: 0x80070003)
I am not familiar with MSBuild so not sure how to proceed.
The error takes me to the following line in the MSBuild code:
GetDependsOnNETStandard Condition="'$(_RunGetDependsOnNETStandard)' == 'true'"
References="#(_CandidateNETStandardReferences)">
<Output TaskParameter="DependsOnNETStandard" PropertyName="DependsOnNETStandard" />
</GetDependsOnNETStandard>
There is an outstanding issue with Visual Studio 2017 and DependsOnNETStandard that should hopefully be resolved in 15.8
I just encountered the same problem today when upgrading a project that was originally created VS 2015 and upgraded to VS 2017.
It looks like the upgrade of the projects misses a few elements in the XML that it needs.
If you edit the csproj files of the effected projects and add
<DependsOnNETStandard>false</DependsOnNETStandard>
to the top PropertyGroup like so:
<PropertyGroup>
...
<DependsOnNETStandard>false</DependsOnNETStandard>
</PropertyGroup>
It should resolve the issue. It did for me.
Details of the issue and discussion around it can be found at:
https://github.com/dotnet/sdk/issues/1544
According to your error log info, seems you are trying to build locally through Visual Studio or MsBuild command not TFS build.
Suggest you to use the latest version of dlls, Microsoft.TeamFoundationServer.Client and also upgrade your Visual Studio 2017 to latest version. For The system cannot find the path specified. issue try to
Clean All Projects.
Unload All Projects
Reload All Projects.
ReBuild Solution
Another way is :
Close the solution
Delete bin folder
Delete all obj folders
Open solution and build
If all of above still not work, suggest you add a more detail log and sample code for troubleshooting.
I am trying to build a program for x64, but I keep getting the following error messages:
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(2554,5): error MSB4216: Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR4" and architecture "x64". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe" exists and can be run.
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(2575,7): error MSB4028: The "GenerateResource" task's outputs could not be retrieved from the "FilesWritten" parameter. Object does not match target type.
MSBuild.exe exists and can be run, so I don't know why I am getting these errors.
I am using Visual Basic in Visual Studio Professional 2013 (Update 4). I am not using any DLLs, all I am creating is a standalone .exe file.
I've tried searching, both here and on Google, but cannot find anything helpful. Then again, I have a tendency to overlook things, so the answer has probably been screaming in my face for the last hour. I apologise in advance if this turns out to be the case.
Any and all help is very much appreciated.
replace
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe
by
C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
and try.it should do some difference.this occurs because the version on msBuild.exe has changed after update4 of vs2013.check for version differences..
also i suspect you are trying to build the solution in x86 architecture.if first solution doesnt work,go to the Build tab, change the Platform target from Any CPU" to "x86" and try. hope it helps.
I just encountered this exact same error in a multiple project VB solution when trying to start a debug instance of one project. By forcing a rebuild of that one project I was able to fix the issue and start the debug instance.
I solved this problem by opening the project in Visual Studio 2017, instead of 2015
When I run my TeamCity build with the only build step being of runner type Visual Studio (sln), I get the following error:
C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1.
This is on a dedicated CI server running TeamCity Professional 8.1.1 (build 29939). There are several other successfully-running builds on this server.
The odd bit is that the same build runs successfully on TeamCity on my dev machine. I followed an answer to a similar question, and copied the specified folders across, but that didn't help.
I'm sure the project/solution file isn't invalid because in addition to the build running on my dev box, I have opened the solution in Visual Studio and built it there with no problems.
Any suggestions?
I just fixed this.
Look inside the Test.sln file for Project or EndProject tags that aren't closed. For us, the EndProject was missing and it broke on teamcity, but no issues in Visual Studio.
It seems the TeamCity error message will occur for any number of root causes. In my case the problem occurred because a line inside the GlobalSection(NestedProjects) section was referring to a project Guid which didn't relate to any project defined in the Solution file.
As with the previous post I didn't have any issues building in Visual Studio. I only got a more helpful error message that allowed me to discover what the real problem was when I built using msbuild.
See https://therightjoin.wordpress.com/2014/07/04/msb4025-the-project-file-could-not-be-loaded-data-at-the-root-level-is-invalid-error-when-building-ssdt-project-in-teamcity for another example, and where using msbuild helped identify the true problem.
In our case, it was a duplicate project reference in the solution file (caused by near simultaneous commits and an automatic merge).
In our situation the problem was specifying a ToolsVersion that was not installed on that machine. (14 which VS2015 has but VS2017 does not have by default)
In my case, after merging, in .sln file, it was a mismatch of lines under
GlobalSection(NestedProjects) = preSolution
{6B971E15-6B61-4AA8-9B93-9639C23269C3} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
{54D14F01-D576-4DE6-9404-D21AD0DC4916} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
... (was some extra entry here )
...
EndGlobalSection
section. In clear words, there were some extra lines added after merging. So, If you have merged, please compare two solution files manually. You can start with total line numbers in both files.
In another Case
We had a blank lines - so make sure any blank lines are removed!
Hope this helps some else too!
I got this same error with Jenkins. It turns out the root Jenkins folder was set to C:\Program Files (x86)\ and it didn't have write access to bin and obj directories.
Error:
error MSB4025: The project file could not be loaded. Data at the root level is invalid.
I launched cmd as Administrator and ran this:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Program Files (x86)\Jenkins\workspace\BuildBI_1\Reports\Test\ReportsTests.sln" /t:Build /p:RunOctoPack=true
And that gave me clues about not being able to write to bin and obj.
This worked for me-
You can install Build Tools for Visual Studio 2017, make sure to select C++ tools, Windows 10 SDK and MSBuild and your set.
Use MSBuild to identify the underlying problem:
$> msbuild mysolution.sln
Gave me this beauty with the correct error line number:
If msbuild cannot be accessed like that from the command line / powershell, try to find the MSBuild.exe shipped with VisualStudio, e.g. C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\MSBuild.exe.
VisualStudio itself seems to be very "tolerant" against errors / inconsistencies in the solution file, so having it open in VS is no guarantee for the sln file being correct.
I fixed it by updating the solution file.
Another possible problem (and resolution): I had a stray unused solution file in my repo, pointing to who-knows-where, and the MSBUILD step in my Azure DevOps pipeline was set to **\*.sln.
I have downloaded libsvm-3.17 package. Extracted the files. I go to 'tools' folder to try using grid.py to look for suitable c and g with the dataset provided in the package, i.e. heart_scale.
However, the following is what I get
Traceback (most recent call last):
File "C:...\Documents\libsvm-3.17\tools\grid.py", line 266, in run
if rate is None: raise RuntimeError('get no rate')
RuntimeError: get no rate
worker local quit.
Can someone help me figure out how to solve this problem.
Thank you very much.
You may need to scale the data in advance. I got the same problem and it sorted out after I scaled the data. Hope this help.
Firstly, if you are a newbie in libsvm, I would recommend you to try easy.py instead of grid.py. Secondly, before executing anything you have to compile libsvm, for compiling follow instructions given in README file (You must ensure nmake.exe, cl.exe, link.exe are in system path), here is what it says:
Windows binaries are in the directory `windows'. To build them via
Visual C++, use the following steps:
Open a DOS command box (or Visual Studio Command Prompt) and change to libsvm directory. If environment variables of VC++ have not
been set, type
"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"
You may have to modify the above command according which version of
VC++ or where it is installed.
Type
nmake -f Makefile.win clean all
(optional) To build shared library libsvm.dll, type
nmake -f Makefile.win lib
Another way is to build them from Visual C++ environment. See details
in libsvm FAQ.
Once you have it installed you can start working with easy.py and grid.py.
This is what I tried on both a 64 bit and a 32 bit machine and grid.py works fine.
I have added the default install directories, if your installation directories are different modify accordingly.
Open command prompt and type
C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\amd64\vcvars64.bat for 64 bit systems
OR C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\vcvars32.bat for 32 bit systems.
Navigate to libsvm directory in the same command prompt and run
C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\amd64\nmake.exe -f Makefile.win for 64 bit systems
OR C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\nmake.exe -f Makefile.win for 32 bit systems
The binaries should be built successfully in the libsvm-3.xx\windows folder
Run grid.py with your options
Within grid.py the gnuplot.exe is usually set at tmp which never worked for me so I changed the gnuplot executable path in my grid.py to the following:
self.gnuplot_pathname = r'C:\\Program Files (x86)\\gnuplot\\bin\\pgnuplot.exe'
If you use the option -log2p to run grid.py, you will get output get no rate. With grid.py, you can't use -log2p option.(No matches for searching -log2p in grid.py)
You can use -log2p option in gridregression.py.