In an ASP.NET MVC3 project I have a structure like this:
Core.csproj
-> 3rdparty1.dll
-> 3rdpartyreference.dll
-> 3rdparty2.dll
Web.csproj
-> core.dll
I'm using the Build Deployment Package feature in VS2010. When I build, there are some references missing in the final bin directory. It only contains the web.dll, core.dll, 3rdparty1.dll and 3rdparty2.dll but is missing the 3rdpartyreference.dll.
How can I force the Deployment functionality to copy all the necessary references? (without manually creating a specific "copy something.dll" instruction in the afterbuild in the csproj)
The MSBuild tasks involved in the deployment package and publish features of VS 2010 fail to pickup indirect references by where your app depends on an assembly that depends on another. Either you can copy the files manually (not recommended), or you can add an unused reference variable to your core project that points to some class in the thirdpartyreference.dll. This reference variable, even if unused, will cause VS 2010 to think you have an explicit dependency on that third party dll and copy it to the bin directory as expected.
The feature you're looking for is called "Bin deployment". In this article there's a step-by-step solution. Basically, you need to add deployable assemblies to your project - specific folder will show up in your project structure where you can add necessary dll files.
Related
I have a project that depends on another project, how can I configure Jenkins to use the reference of that project in the workspace.
For an example, project B depends on a certain set of classes from project A. Jenkins should be aware to build project A first and then B.
The trigger point is when a commit is pushed to the master of project B.
If a project depends upon another project, it is typically part of the same solution and always part of the same source tree. This means the slave will probably have the source already - or if it doesn't, the step that obtains the source needs the workspace mapping updated to not exclude it.
Also, when a project depends upon another project, the reference information includes the path to the referenced project. In the absence of solution file, this is used directly to build the other project with the same configuration (as in Debug/Release).
It's usually best to use a solution file instead of building projects directly as that ensures platform/configuration customisation is honoured as well as determining the correct build order of the projects.
So I got it sorted out. Since my project was based on project reference, the path had to be the same.
Naming the Jenkins project folder same as the dependent project name I referenced solved the issue.
I was under the impression that another workspace can't access another workspace. But it seems to be Jenkins handles it internally when building projects.
I am trying to create Team City build template which requires minimum customisation, and I want it to play nicely with legacy projects and projects developed with .NET Core/Standard and .NET CLI.
I am stuck with NuGet as there were some considerable changes in how things work.
Earlier we had to create nuspec file to pack project as a NuGet package. At least in that file we could define various package-related properties.
New csproj file format allows us to define all package properties inside itself. That's fine, but how then do we know which projects should be packaged and which should not?
So far our TeamCity's build step Pack NuGet just contained **.nuspec for Specification files: field. The very fact of nuspec file presence served like a flag pack & publish this project.
However, for dotnet pack we need to specify the project. There is no simple way to distinguish 'main' projects from 'auxiliary' ones on which mains depend. (Let us ignore that project-to-project references are currently not supported.)
We either could pack all projects specifying **.*proj (yet in that case we are to know which packages to publish) or we might specify projects explicitly in a build configuration, but I don't like this approach because you must edit build configuration each time new project is added to the solution.
I also considered the option Generate package on build and omit dot net pack step as package is created on build. The only thing left is publishing the packages with dotnet nuget push specifying **/%BuildConfiguration%/*.nupkg.
Unfortunately when starting build against solution without projects with enabled Generate package on build makes TC fail complaining that
Target files not found for pattern "**/Release/*.nupkg"
Hence, I either need another recipe for achieving the required result or an advice how to make TC consider empty result just as a NOP and mark build as successful.
Yet another option is to use nuspec even for new csproj...
Since TeamCity 2017.2 will be available option to associate build configuration with multiple templates. So you will be able to create different templates to create packages for old projects and new .NET CLI projects.
To specify paths for target .NET projects, which should be packaged, you could use build configuration parameters.
To set such parameters during the build you could send in the preceding build step service message. The value of this parameter could be set to the list of target project files which could be selected via script like that: https://stackoverflow.com/a/8153857/305875
I have an ASP.NET (4) Web App solution with 3 projects. Project A references B & C (along witha bunch of other 3rd party DLLS like Crystal Reports etc).
I have 3 build configs, Debug, Test & Release.
If I do a build in any of the configs, the built DLLS (and PDB if it is Debug) are placed as they should in their respective folders.
So Test gets built into {root}\bin\x86\Test
Release into {root}\bin\x86\Release
Debug into {root}\bin\x86\Debug
Also, all the dlls that are referenced have their 'Copy Local' property set to true and so they are copied into the {root}\bin folder so I can run and test locally in VS.
BUT
The main app DLL (ProjectA.dll) is not being copied into the {Root}\bin folder when it is being built/rebuilt, just being left in the folder for the chosen build config as described above. So when I run the app in VS I get an error 'Could not load type 'ProjectA.Global_asax'. Not surprising given the main project DLL is not in the Bin folder where the web server is looking for it.
The only way I can get it to run is to manually copy the ProjectA.dll into the {Root}\bin folder myself which seems a nonsense and obviously fraught with the risk of me forgetting to copy the latest on over after each build.
Surely there must be a way of telling VS to copy the main app dll (ProjectA.dll) as well as all the referenced dlls, into the main {Root}\bin folder?
Obviously, as ProjectA.dll is the main app assembly it is not in the list of references so I cant just set the 'Copy Local' prperty for it. Unless it is hidden away somewhere else? I have trawled every form and dialog in VS (and hours on Google!) and just cant see how to tell VS 'Please copy the main app assembly back into th bin folder when you have finished building'.
Can someone pls help ths is driving me nuts!
Many thanks
Mark
If you just want avoid the manual work of moving the dll after every build, then you can create a Visual Studio post-build event to copy the dll. Some examples here and here.
I am using Visual Studio 2010 to manage a web application. This web application is organised into a number of projects, where the UI itself is one project, and the business logic resides in another assembly which is then set up as a project reference for the UI, and makes calls out to code in third-party libraries.
When I do a deployment build, MSBuild creates the usual _PublishedWebsites folder and copies the web application into there. What it does not do is copy the dependencies of the business layer, which means nasty YSOD when I try to run the application. Now, I can set the third-party libraries as references of the UI project, and that ensures the libraries are copied and deployed as expected - however, that rather misses the point of having the business layer doing all the work, and means additional maintenance in that when another third-party library is added, it needs to be added in more than one place.
How can I ensure, once and for all, that dependencies of my business layer are deployed to the _PublishedWebsites folder when the deployment build is run?
As per my comment to #Shaun Plourde's response, it appears that this scenario is not supported. If you want indirectly-referenced assemblies to appear in the build output, you'll need to reference them directly.
This should just work out of the box with VS.NET. Try setting "Copy local" to true where the dependencies are actually needed. Your UI project should not require any explicit references to those assemblies.
For smaller projects, this may scale fine in terms of compilation performance. For larger projects, you may want to consider alternative approaches such as those outlined in Patrick Smacchia's article at http://www.simple-talk.com/dotnet/.net-framework/partitioning-your-code-base-through-.net-assemblies-and-visual-studio-projects/.
It isn't a perfectly automated solution, but you can solve this with a post-build script on your main project.
I've found that the $(WebProjectOutputDir) variable is managed such that it resolves to the "_PublishedWebsites" directory when you supply an output directory that is not equal to the directory of the project being built. (Otherwise, it is the same as the current project directory.) So, for your problem, you could put this in the post build of your web application:
xcopy /Y /S "$(ProjectDir)..\Your Business Logic Project\bin" "$(WebProjectOutputDir)\bin"
It should work both on your machine and on your build server.
I noticed today that whenever I build a word add in project of mine, Microsoft.Sharepoint.dll is being copied into the bin folder and is subsequently included when publishing.
Is there an easy way to see why this (annoyingly large) dll is being included when publishing?
It isn't referenced directly. There are 3 dependencies in the project page and I've checked all these projects and none of them reference it directly either. Do I need to continue following the dependencies of those projects too?
Is there not some kind of log file for a build that could give me a hint?
EDIT:
The problem was that my project referenced a project that referenced a project that had a reference to Microsoft.SharePoint.dll with copy local set to true. I had to delete the dlls from all projects and rebuild with copy local set to false. I didnt realise that the 3rd party dll would be copied into my project.
If this is being pulled in due to a dependency from another DLL, then try looking at all of your DLLs in Dependency Walker. It finds all of the dependecies that a dll has. This is usually only when they are actually being used/bound, but you can also use the Fusion Log Viewer to see where all DLL binds are being bound from.
You could have a a look at reflection mechanism of asp.net or if not you could run trace using firebug for cross reference on browser ,