I'm trying to build a project with TeamCity Professional 6.5.2
I have a MVC Visual Studio 2010 project using a visual foxpro dll.
The build fails because the dll is not registered.
How can I register that dll in the build machine, as part of the build process?
Thanks!!
There are two different scenarios Rodrigo, your scenario will fall into one of these:
Assemblies which can be referenced by the project: Wherever possible, include dependent assemblies in your source control repository (the 10th Commandment), usually in a "libs" folder which is referenced by the necessary projects. This centralises all your dependencies, makes it easy for new developers to get started and solves your TeamCity build problem.
Assemblies which need GAC installation: There are times when the assembly simply has to be installed in the GAC (i.e. RightFax). Frankly, the easiest thing to do in this case is just to install the damn thing in the GAC. It's an exception and whilst some people will philosophically argue against it, alternatives can get a bit complex (i.e. automating installation as part of the build), and for money I'd rather invest the time elsewhere.
Installing assemblies on each machine (dev, build, prod) will make future updates and any continuous integration system difficult to maintain in the future.
It would be better to create a folder in your working directory (I call it "Resources") which contains a folder for each group of DLLs. Then you just reference the assembly directly from the Project each time. You get duplicate DLLs across different projects, but it keeps everything very clean and simple.
In Visual Studio 2010 you can download a little utility called NuGut which I believes helps to manage assemblies in a better way.
It is a bad idea to register all DLLs on build agent machine, sometime you can find out that you have to install Visual Studio on a build agent machine, for instance ;)
I would suggest to place such libraries along with your code base in Source Control system (I assume you are using it), and just reference lib's folder by declaring a MSBUild property like
<PropertyGroup>
<LibFolder>$(PathFromCommandLineOrJustHardCodedPath)</LibFolder>
</PropertyGroup>
And then before doing a Build/Compile just copy files from $(LibFolder) into the build $(OutputFolder) using standard MSBuild command Copy by specifying source and destination files, and thats it.
To force TeamCity to pickup Lib (dlls) files from VCS folder just add path mapping into the:
TeamCity Configuration Settings -> Edit Build Configuration -> VCS Root settings -> Client Mapping
EDIT:
In your case looks like you have integration test which depends on external COm Server which you need to launch, so you can programatically registr this DLL, for instance in TestSetup, and then do not forget to unregister it in test TearDown.
Anyway you have to just reference this DLL as
VS Project -> Add Existing Item -> Add as Link
+ set
Copy to Output Directory -> Copy if newer
How-To register COM dll: see this SO post
Finally I added a prebuild event in Visual Studio running the regsvr32 command. The dll was in a known location, so I referenced this way:
regsvr32 /s $(SolutionDir)Lib\ProjDataAccess\ProjDataAccess.dll
Agree with Troy Hunt.
For a Continuous Integration with TeamCity 8.0.2 where you need an assembly (custom made shared assembly) reference from GAC, do the following.
1. Add the assembly to the build pack (In my case its nuget package).
2. Before starting the build process (MSBuild, Visual Studio etc), register the assembly to GAC with the help of a command line build runner.
3. Continue with the build process.
By following the above steps, if you are using MSBuild, the build process can link to a valid reference from GAC, which can produce an expected build result.
In my case, where the code refers a custom component from GAC, MSBuild ignored the assembly reference and completed the build process without an exception. But the deployment with the build output failed. To overcome this situation, I've used the give steps.
Note: It is mandatory that the TeamCity agent needs to run under an elevated user account. Else the addition to GAC won't be permitted and the build process can fail.
Related
I have a solution that contains both C++ and C# projects that is built in a nightly CI build on a remote machine. The build script checks out a clean copy of the source and builds both debug and release configurations of the solution using MSBuild and runs the test suite on each configuration.
About every other build, the release configuration fails to build properly. An analysis of the build log reveals that C++ Project Q, which depends on C++ Project D, tries to link before Project D is done. This error only happens for the release configuration on this particular build machine - the debug configuration builds without error. I have a separate nightly build process that runs on a separate machine where the release configuration is built with a similar script that uses MSBuild (it just does not run the test suite), and it builds the same source revision without issue. Multiple team members build the solution without issue either from update or clean checkout with one or both configurations, always from the Visual Studio 2019 IDE, on various operating systems.
Project Q is configured with Project D as a project reference and Project D is also listed as a hard-dependency for Project Q. As I mentioned, the build script is using MSBuild.
An additional item of interest from analysis of the release and debug build logs: The build of Project D is initiated differently between the two configuration builds. It is started by its own metaproject in the release configuration (as item 60, for instance), but started earlier (as item 44, for instance), by a different project in the debug configuration. Not sure why the dependency algorithm would run with such different results in the two cases since the solution and working source being built are the same.
Any ideas or suggestions would be appreciated.
Update: Inspection of differences between the release and debug build logs reveals some interesting facts. In the failure case I did a search for ") is building" in each log - should be an indication of how many projects were built, including metaproj entries. For the failure case, debug had 282 occurrences, whereas release had 175. For the success case, debug had 280 occurrences and release had a whopping 559! A similar search for "Done Building Project" yields similar results, only off by 1 or 2. That might partly explain the differences in build order between the solutions. I also need to check for conditional build entries.
Visual Studio 2019 Reference Project Not Built Before Dependent
Project Tries To Link in Release Configuration using MSBuild
It seems that project buid order was broken and Project D built later than Project Q which need the output content of Project D, so the whole build failed.
Not sure that if you use Project Dependency(Right-click on project-->Build Dependencies-->Project Dependencies), if so, only VS IDE Build Will recognize their build order while MSBuild command line will lose the relationship about them.
Besides, I wonder if your main project under Release mode references a dependency project under Release mode. If you did these, the build will definitely go wrong.
All of these above is that I think you made some changes to your project.
You could follow these steps:
1) I suggest you could try to use Project Reference and it will add these xml node in ProjectQ.csproj file to strongly specify build relationship:
<ItemGroup>
<ProjectReference Include="..\ProjectD\ProjectD.csproj">
<Project>{26c26cdd-a5e0-40c7-b0c9-4563f969424f}</Project>
<Name>ProjectD</Name>
</ProjectReference>
</ItemGroup>
Also, check if there are any conditions that distinguish between Debug or Release mode when referring to a project like this:
<ProjectReference Include="..\ProjectD\ProjectD.csproj" Condition="'$(Configuration)'=='Debug'">
If so, please remove that condition Condition="'$(Configuration)'=='Debug'" to make sure it is the same between Debug and Release mode.
2) close VS Instance, delete .vs hidden folder under solution folder.
3) check your CI Build and cloud build server and ensure that cloud parameters are consistent with other servers. And examine any of your xxx.csproj files to check if you have any other operations which causes this bahavior.
In addition, if necessary, you can share your xxx.csproj file and the build script with us to troubleshoot it.
I have a dot-net project build with VISUAL STUDIO 2015 4.6.1 framework and I have two independent program folders in the source code which has some build errors. There are no references to these programs from the main program.
When I push the whole source code onto VSTS I get build errors. So now I need a way to exclude those two folders from the manual build for now but may need them later after they are debugged so I don't want to delete them from VSTS too.
Can someone suggest?
Use an MS Build project file. Create an MSBuild project file from scratch
And the at the build solution step in VSTS, select or type the project file path instead of the solution file.
You will have to remove it down the road though. The maintenance tasks tend to be hard and counter-intuitive whenever the code base grows quickly. Visual Studio will not warn you if you have build errors (like obsolete path) in the MS Build project file.
I build my app either as x86 or x64. This app uses external DLL.
I have x64 system (Windows 10) with the same DLL library installed for both platforms - x86 and x64. They are placed in same folders inside appropriate Program Files directory. I can manually set path to either one in environment variable PATH and it woks. But it is a little incovinient to rewrite PATH and reset computer when I switch platform and want to test the other one. Is there any solution, how system automatically loads correct DLL from correct Program Files dir?
I have found solution for running apps from Visual Studio: How do I set the path to a DLL file in Visual Studio?
It is working as epxected. If I run app outise Visual Studio, I set PATH variable by myself and is also working.
Copy the DLL in the build location next to the executable, for Visual Studio this is typically \Debug or \Release in a architecture dependent sub directory (i.e. x86 or x64). Just make sure the target / output locations are set correctly in the project settings.
You have to copy only once, or more correctly: each time after you 'clean' the solution. To make this easier, many people use a dll-copy script (use batch, ruby or python) and have it run automatically before building or after cleaning. You can execute the script in a pre-build step or post-build step that can be configured in your Visual Studio solution or project settings.
There is also a more robust way to handle build artifacts and peculiarities: I highly recommend the use of CMake to keep the build matrix organized. It is provides a general cross-platform approach to script pre-build and post-build actions such as tracking dependencies, copying files, packaging installers, deployment, version verification, versioning, etc.. it comes with an easy scripting language so you can build macro's and functions to do your copying. It can be a bit of a learning curve to get it right, but once it's there, it provides a robust dependable way to build out your project build pipeline.
I'm working on a big code base which has many solutions and many more projects.
When I write unit tests they often depend on a number of dlls being present which are built by other solutions into different output folders to my current solution.
I usually add build steps to copy required dll's to the current solution's output folder so that they can be found when I run unit tests. This can end up in a lot of wasted space and confusion with duplicate dlls and which is the master copy of each dll which is the one that should go into the installer.
Is there a better way of adding additional search directories?
I was considering having a TEST_MODULE_INITIALIZE that will AddDllDirectory() and then marking the dll's as delay loaded so that when they do load the added dll directory will be searched. But, I don't think that works as you have to mark the dll's as delay loaded in the exe. But, the exe is the testrunner which is out of my control.
Your consideration is absolutely right. You can load dependency dlls in VS testrunner context, as sure as a gun, in this way:
1) setup your test project to deploy all required dlls into output dir (for example with the help of pre\post-build steps)
2) set delay loading of dlls in test project settings. (Test project-properties-Linker-Input-Delay loaded dlls = enter list of dependency dlls)
3) Setup directory to search dlls. It could be either TEST_MODULE_INITIALIZE or TEST_CLASS_INITIALIZE. Simple case is to use SetDllDirectory for this purpose. If you want to use AddDllDirectory - use it carefully:
If SetDefaultDllDirectories is first called with LOAD_LIBRARY_SEARCH_USER_DIRS, directories specified with AddDllDirectory are added to the process DLL search path. Otherwise, directories specified with the AddDllDirectory function are used only for LoadLibraryEx function calls that specify LOAD_LIBRARY_SEARCH_USER_DIRS.
It may not be the best method, but since you're using Visual Studio 2013, you should look into test settings to control what is deployed when you run your tests. Inside of test settings you can specify files or folders in the Deployment section which will allow you to select files outside of your current solution. You can create multiple test settings (one for local and one to use on a build server if the paths to these files are going to be different).
Again, maybe not the best solution, but it has worked for me in the past.
Specifying Test Settings for Visual Studio Tests -
https://msdn.microsoft.com/en-us/library/ee256991.aspx
I am new to Visual Studio, and I am trying to figure out the best way to organize my projects.
I am writing an application using the sfml library, and I have various resources (images/sounds) that I am using. I dropped these into the project folder, and everything works fine when I launch my application from Visual Studio.
I am wondering though, how does this translate to when a program is deployed? If I go into my solution's debug folder, and try launching the exe, it is unable to locate any of the resource files. Am I suppose to tell Visual Studio to copy files to an appropriate directory, and if so how?
Thanks for any advice or links.
For slightly more complicated "deployment" scenario, you can use post-build scripts to copy the correct files into the output directory and even package it into a zip file, for example.
If you find yourself writing more than one page of batch you may want to consider the options below, because batch is a PITA to debug.
Recent MSVS project files are actually MSBuild files (just open the .vcxproj file in Notepad or Vim). For instance you can use the Copy task, invoke arbitrary programs using the Exec task, etc. It can be a bit more sophisticated than the batch script in post-build scripts. MSBuild 4 can use Property Functions making it quite expressive. Useful reference if you do this
For a "full blown" project, you'll want to roll a dedicated build system using a dedicated MSBuild file, NAnt or even higher level wrappers like Rake.
As a less popular alternative, in a previous project I built a small dedicated "builder" .exe project in the solution and have other projects depend on it. Then in the post-build scripts of the other projects I just invoke the builder projects with arguments to make it perform certain tasks. The advantage is that you can write C# (or F# or VB.NET) and not have to fight the build system (as much) and I think it works quite well for small-mid sized projects.
for my project, I direct everything into one directory.
Go to ur project configuration, change General->Output directory, General->intermediate directory, and Debugging->Working directory to one directory. The reason you cannot locate the resource files is because the debug directory is not the same as the output directory.