I downloaded ChartFx Lite and am using it successfully in my windows forms application on my development machine. I have added the ChartFX.Lite.dll assembly to my source repository and am trying to build the project on my build server that does not have ChartFx Lite installed. I get the error:
Exception occurred creating type 'SoftwareFX.ChartFX.Lite.Chart, ChartFX.Lite, Version=6.0.839.0, Culture=neutral, PublicKeyToken=a1878e2052c08dce' System.ComponentModel.LicenseException: Couldn't get Design Time license for 'SoftwareFX.ChartFX.Lite.Chart'
What do I need to do to get this working without installing ChartFx Lite on my build server?
If you just want to test the build, you can suppress the lines concerning ChartFx from the .licx file created by Visual Studio. It should build this way, but probably will not execute correctly, as the license will not be included.
The .licx file contains instructions to include binary license resource during build. I'm afraid that if you want a real build you have to install ChartFx on the build server.
Related
We have a number of .NET Framework projects with a "nuget pack MyProject.csproj" command in the post-build step. We have been using VS2010 (:O I know) until now, and it has been happily spitting out nupkg files.
We recently updated our build tools to the 2019 version (running the new version of varsall.bat before calling msbuild), and the "nuget pack" command now fails:
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project has been built.
What I've tried:
Adding a "nuget spec" step before packing
Upgrading the nuget CLI executable to the latest version
Updating from packages.config to PackageReferences
This allows you to use MSBuild -t:pack. However, two issues:
When running this in the post-build step on my machine, it starts dozens of cmd & MSBuild processes and pegs my CPU.
Our developers are stuck on VS2017 for now, but the 2017 build tools are no longer available for our build server (so we use 2019). The 2017 & 2019 installs put MSBuild in different locations. We could set path variables for all the machines, but that seems brittle.
I'm playing with upgrading one of the projects to the new csproj format, but it is rather involved. Upgrading all of our projects will be an effort all its own, and I'm still exploring the ramifications.
Is there something simple I'm missing which will allow this to work without large modifications?
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project
has been built.
This message indicates that the nuget.exe can't find the output assembly. So you must make sure the assembly is created successfully.
And one point you need to take care, normally we use command like nuget pack foo.csproj -Properties Configuration=Release to pack the assembly built in release mode. If you use command like nuget pack xx.csproj in post-build-event, no matter which configuration you use msbuild to build the project, nuget will always try to find the assembly in ProjectDir/bin/debug.
So when you deploy the project to remote server without bin and obj folders, if you try to use command like msbuild xx.csproj /p:Configuration=Release, the build is in release mode while nuget.exe will search the bin\debug instead of expected bin\release. You should check if you're in same situation.
Why does NuGet pack break with VS2019 build tools?
This issue is not about the build tools package. Since the error message you got came from nuget. Msbuild just help call the nuget.exe, and the cause of the issue is nuget.exe can't find the needed assembly by one specific path. Please check if the path in the error message is right, and then check if the assembly is in that path.
I also ran into the same issue during our TFS upgrade to Azure Devops. The new Nuget task doesn't have the switch for -Build. The fields in the Nuget task screen for Pack also doesn't allow you to add this switch, that's why it's complaining about not finding the dll or the output of the build. I modified the nugetpack.js file on the agent's task folder to test the theory and now the pack options build successfully.
This is the line I added to the js file (towards the bottom of the page):
nugetTool.arg("-Build");
what would be nice is to have this option represented as check box to cover if there is use case to call Nuget pack without -Build switch
I am trying to build a .NET 4.6 project using MSBuild 15 on our build server (using CruiseControl).
The project has a NuGet package reference (to Oracle.ManagedDataAccess) and it gets restored correctly.
However, the build task fails with the error "The type or namespace name 'Oracle' could not be found".
I have tried building the project in VS 2017 on the build server using the same account, and it works.
I expected MSBuild to retrieve the package contents from the same location, but apparently it can't. What could be the reason?
The error seems to have been caused because MSBuild 14 was used in the build task instead of MSBuild 15. Not sure exactly why that made it fail, but it works now.
I've got a couple of ASP.NET vNext applications and I want my CI server to also be able to build them. Both my local machine and the CI server are running VS2015 RC. Then we've got VS Online and a local build controller - which is the server mentioned.
However, I cannot get builds going since it seems to be looking for v12 tooling - which does not include anything DNX.
So - building the solution gives:
The Dnx Runtime package needs to be installed. See output window for
more details
It is installed - since it came with VS2015 RC, AFAIK. So I thought the build template isn't using v14 tooling. I downloaded the Default Git template v12. And indeed it says:
<this:Process.BuildProcessVersion>12.0</this:Process.BuildProcessVersion>
So I switched that to 14, uploaded template, ran build. Then:
Exception Message: The build controller used for this build does not
support the version of the template file used by the build definition.
The version of the template file is 14.0. The maximum supported
version for this build controller is 12.0.0.0.
So trying to solve this - got me to this forum question that states:
Then, instead of changing the BuildProcessVersion property, you need
to change the involved MSBuild version. Open the build process template, find the Run MSBuild for Project activity, change the ToolPath property to the 2013 version msbuild
So - I checked out the template - there is no ToolPath version. There is a ToolVersion property however - which I'll try setting to 14:
In short, my question is: how can I build ASP.NET vNext apps on my build server, that has VS2015RC installed - but is building using v12 tooling?
UPDATE
Seems that the problem is not as much in using the wrong tooling, but more in finding/using the correct DNX runtime while running under a service account ( which the TFS agent is doing ). I've added an issue for the DNX team: https://github.com/aspnet/dnx/issues/2239 .
use msbuild parameter /p:VisualStudioVersion=14.0 ,which can be added in build definition .
I am using ASP .NET MVC 4 with Entity Framework 4.5
I downloaded the nuget something to be able to export my data pro PDF and found one called RotativaW7. The project is working normal but I try to check in the project to publish to TFS and is giving the following error message:
ERROR: Multiple errors occurred during the operation, the first of which is displayed below. A full error list is available in the Output Window.
..\packages\RotativaW7.1.5.4\RotativaW7.1.5.4.nupkg: Unable to write data to the transport connection: The cancellation of an existing connection was forced by the remote host.
nuget:
Install-Package RotativaW7 -Version 1.5.4
Could anyone help me solve this problem?
The nuget package contains an .exe, are you sure TFS allows you to check in executable files?
I am trying to set up .Net builds on our Hudson (CI build) server. One application uses Microsoft.Office.Interop.Excel.dll. This is not found on the build server and causes the build to fail.
I obviously don't want to install Office on the server just for this case so what do I do?
To clarify: this is a build server. The project is not run on the server and Excel is not needed except to satisfy the compiler.
Install the primary interop assemblies:
Office 2003: http://www.microsoft.com/en-us/download/details.aspx?id=20923
Office 2007: http://www.microsoft.com/en-us/download/details.aspx?id=18346
Office 2010: http://www.microsoft.com/en-us/download/details.aspx?id=3508
Those PIA's should be also deployed to the GAC when you install Visual Studio (if you can).
You might also take a look at this question: Unit test with Microsoft.Office.Interop dll fails on build server
This is straight forward if you are using nuget and any repositories like nexus for dependency management. In our project we use VS2017 which has msbuild nicely integrated with nuget and it does the job to download this dll locally and on build server.
Hope this helps