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
Related
I have a dll project which I need to install into the GAC, on our Production machines.
(I wish I didn't have to use the GAC but SSIS insists)
gacutil.exe is not available on the target machines and using "Enterprise.Services" from PowerShell does not work (I don't know why)
My understanding is I should created a msi installer project.
However after installing the Setup and Deploy Extension to Visual Studio (2015 soon to be 2017), I discovered those projects cannot be built by our Build Server because it uses MSBuild, and MSBuild can't build vdproj project files.
What is the correct way, using a CI build pipeline (MSBuild), to create build artifacts, which can install dlls to the GAC, of a Production Environment?
Note: there are several partial answers on SO, but I could not find any, which were up to date/answer my whole question. Please keep that in mind when answering.
You need to break this down into several user stories. You aren't finding partial answers, you are finding actual answers for specific questions. What you ask is more like an epic.
In general I would create an MSI using Windows Installer XML. WiX/MSI can install files to the GAC without using GACUTIL. If you use the WiX Visual Studio extension "Votive" you can create a .SLN / .WIXPROJ / .WXS that can be built using MSBuild. You can then put this into a source control system such as Git/TFVC/Subversion and use a build system such as VSTS V.Next Build, XAML Build, Concourse, Jenkins to automation the pipeline to build the MSI.
Visual Studio Online and gated checkin, ASP.NET vNext project.
I have a solution with asp.net vnext project (*.kproj extension)
Enable gated checkin on Visual Studio Online and enable unit tests for each checkin.
After checkin in logs error:
C:\a\src\Dev\project\MyProj\MyProj.kproj (7): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\AspNet\Microsoft.Web.AspNet.Props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
How to solve this error and what is this "Microsoft.Web.AspNet.Props"? In solution and projects I don't see refereces or something else with name "Microsoft.Web.AspNet.Props"?
Why used v11.0 version? I think should be used v14.0.
The build servers provided by Microsoft as part of the hosted build service are production servers and don't run pre-release software.
If you want to have a build server with Visual Studio 2015 (v14) then you will need to create one yourself. You can easily use your MSDN allowance to create and run a build server on Azure.
We have recently added AppFabric as a caching option in our project (Windows server version, not Azure cloud). The project thus now has a dependancy on Microsoft.ApplicationServer.Caching.Client.dll and .Core.dll.
Our build server is Windows 2003 and thus AppFabric cache cannot be installed onto it, thus these assemblies are not available.
Short of including the afore mentioned assemblies as explicit binaries in our SVN repository, and referencing them directly (yuck), are there any suggestions as to how to build the project?
Secondly, if we checked in the binaries, performed the build then deleted them from the output folder, is there a way to force .NET to search the %windir%\system32\AppFabric\ folder for the assemblies?
MS do not register them in the GAC...
If your application is using an assembly that can't be installed on your build server, then the solution is to upgrade your build server to Windows 2008.
We have migrated few projects from TFS2008 to TFS2010 by using the method-
1.Attch TFS2008 DB to TFS2010 DB
2.Tfsconfig import
3.Delete the project not required.
There are few projects in the migrated projects which use VS2005. They do not want to do any change in their project and want to use VS2005 to work with migrated projects. We have applied couple of patches in VS2005 and now they are able to access the TFS2010 projects from VS2005.
However we are clueless about the build configuration. We have configured build server for their Collection...now what configuration needs to be changed in TFsbuild.proj to make the build run again.
Is there any more steps required to make the build work?
Any help would be very much appreciated.
Thanks Upfront.
Kabir
If you have not had a build definition for you TFSbuild.proj then you will need to create one. In your build definition, you will need to choose UpgradeTemplate.xaml as the build process template. In TFS 2010 this template is used to run legacy build definitions.
See how to run build with the UpgradeTemplate.xaml here.
I also found this useful post in the MSDN Build Automation forum that tells you the differences between 2010 and 2005 build processes.
On a Windows Server 2003 R2 with .NET 4 SDK but without Visual Studio 2010, I have tried building a Visual Studio 2010 solution with
msbuild MySolution.sln /p:RunCodeAnalysis=true
but that fails.
What is required to run code analysis on such an environment?
I get this error message:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(129,9): error MSB6003:
The specified task executable "FxCopCmd.exe" could not be run.
Could not load file or assembly
'Microsoft.VisualStudio.CodeAnalysis.Sdk, Version=10.0.0.0, Culture=neutral, PublicKeyToken= b03f5f7f11d50a3a'
or one of its dependencies.
The system cannot find the file specified.
I have installed FxCop from the SDK and without luck pointed the variable FxCopDir to the installed location of FxCopCmd.exe, and also setting this registry entry to that location:
HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Setup\EDev#FxCopDir
I had the same problem on my MSBuild server and fixed it by:
Installing Windows SDK 7.1
Setting up the registry keys FxCopDir and StanDir in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Setup\EDev (in Win32).
I then copied over from the dev PC, to the FxCop folder on the build server, the following:
The folder Rule Sets (default installation target is here: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\FxCop)
Microsoft.VisualStudio.CodeAnalysis.Sdk.dll
Microsoft.VisualStudio.CodeAnalysis.Phoenix.dll
phx.dll
Do a search for them on your dev PC with Visual Studio installed to locate them.
Then use the .NET 4.0 version of gacutil.exe to install Microsoft.VisualStudio.CodeAnalysis.Sdk.dll to the GAC.
You should then be able to run code analysis as part of an MSBuild build and have it work properly.
An alternative to FxCop would be to use the tool NDepend that lets write Code Rules over C# LINQ Queries (namely CQLinq). Disclaimer: I am one of the developers of the tool
More than 200 code rules are proposed by default. Customizing existing rules or creating your own rules is straightforward thanks to the well-known C# LINQ syntax.
Rules can be verified live in Visual Studio and at Build Process time, in a generated HTML+javascript report.
Another option might be calling FxCop executable as a build task (from msbuildtasks), saving the result as an XML file that can be parsed within most of the CI tools (like Hudson and CC.NET)