So the problem is quite simple: My project references assembly X but not Z. But assembly X does reference assembly Z. Assembly Z updates somewhat frequently, so whenever I build my project, I'd like to get the latest version of Z as well.
So far I've come up with 3 options:
reference the assembly Z. This has the advantage of getting the new version, always. But it does pollute the references with something that isn't strictly required in there.
Add a post-build event that copies the required DLL(s) from where they are updated. I think this is quite ok, until I need multiple different DLLs, which would make the script quite long and tedious to maintain.
Add the assembly Z as a resource and set copy to output to true. This one I would probably prefer, except that when I add the DLL to the project, visual studio actually copies the (then) current version in to the project, and there is no link to the original source. Thus, when the assembly is updated, this is not reflected in any way in my project. Unless I combine this approach with option number 2, but then I might as well just use option 2 alone.
So, am I missing something, or are these my only options?
I would go with option 1. I think it's entirely reasonable for your project to reference everything it depends on, even if those dependencies can sometimes be indirect.
It also seems like the simplest option to me - and one which fits in with Visual Studio's view of code dependencies that your app requires... so anything that Visual Studio does with those dependencies should just naturally flow, rather than you having to think about this at every stage.
EDIT: As an alternative option, have you considered using NuGet? That way you'd only express a dependency on X within your project's NuGet dependencies, but it would "know" that it depended on Z. I believe it should all just work... You should be able to do this even if these are internal projects, as you can set your own NuGet source rather than the public repository.
Related
Is there any build time impact ? We have around 30 projects in our .Net solution and they shared projects are added by project reference. I am thinking to change to dll reference instead to see if there is any build performance gain.
Did anyone have experience on similar lines ? Please share your thoughts.
Yes, there is potentially a huge impact depending on how you have your CI set up.
The solution to this is to group logical sections of your application (data access, presentation, whatever else) into separate solutions and turn them into NuGet packages. I've had a lot of success combining TFS build, Release Management, and NuGet to automate the continuous delivery of NuGet packages from "prerelease" to "stable".
You can have it package up PDB files as well for debugging purposes, and using NuGet also helps with sharing code between different disparate projects. If Project A is using version 1.2.3 of Package X, but you've updated Package X to version 2.0.0 for Project B, Project A can happily keep consuming version 1.2.3.
One thing to keep in mind when doing a split like this:
const variables are replaced at compile time across all assemblies with the literal value. If you change a const value in Assembly A, and Assembly B references the const value, the value will not change in Assembly B if you don't recompile it. You can avoid that by using readonly fields instead of const.
I don't know why DLL references would save you time, the only added expense of project references is solving the dependency tree, which is something you definitely want it to do.
Otherwise if you aren't careful you will end up with a project that breaks every time you rebuild and requires a couple normal builds to start functioning again.
We are doing a project that uses interfaces and Unity to resolve concrete implementations of classes.
My questions is the following: I need to get my dll's all into the same folder otherwise unity will not be able to resolve the interface etc. So according to me I have a couple of options:
1. Add the projects with the implementations as references and let VS copy the files to the output folder (for some reason this just feels like a hack)
2. Change the build location of all my projects to build to the same folder
3. Create a post build event to copy all the files needed to whereever they need to go
I have implemented to second option but this could lead to files in your build folder that should not be there. I am not a big fan of post build events, so I would like to ask from other people using Unity what they found to be the best solution for them.
Thanks in advance
The first approach sounds like the right one to me. Your project does depend on the implementation libraries; it doesn't express that dependency directly in code, but it requires them, so it seems reasonable to add a reference to them.
This is basically the same situation as where you've got three projects, where project A depends on project B, which depends on project C - you need to explicitly add project C as a reference within project A. Visual Studio doesn't work out transitive dependencies for you (at least it didn't the last time I checked).
something that should be so simple in .net seems to be oh-so-hard.
I have a project called MyExtenders, containing a few simple extenders to basic types.
Many projects use MyExtenders - and so in traditional svn checkout and build approach I add MyExtenders as an svn:external with the revision locked to whichever it was last built and tested at.
Now if I have two projects both requiring MyExtenders added to the same solution it all falls in a heap. I cannot add both MyExtenders to the solution - so I have to use just one - which in the case of different revisions means re-testing the older project with it.
A diagram possibly best explains the dependencies:
SolutionA
->ProjectA
->->MyExtenders r350 (svn:externed by ProjectA)
->ProjectB
->->MyCryptography r800 (svn:externed by ProjectB)
->->->MyExtenders r800 (svn:externed by MyCryptography)
Delphi/C work with the above just fine - all references are from their own project folder.
VS insists on losing the directory structure and flattening the above to:
SolutionA
->ProjectA (refers MyExtenders)
->ProjectB (refers MyCryptography)
->MyCryptography r800 (refers MyExtenders)
->MyExtenders r350 || r800 - my choice
And me being forced to modify one of the projects to refer to a different MyExtenders, and a different revision at that.
Clearly I'm doing it all wrong.. but how do you do it right?
There really is no way around this: if you have two different projects depending on different versions of the same assembly, you are bound to have conflicts regardless of how you manage the inter-project dependencies. To see why this is, imagine that all your source conflicts could be solved somehow - now what will you do upon deployment? Which assembly version of the dependency gets loaded? Whichever it is, it will likely break the depending assembly which needs the other version.
If you have a design which requires a shared library among various subsystems, and those subsystems live in the same process (ok, technically, the same AppDomain), you need to have the same assembly version for both.
This problem goes away if you can get the depending assemblies separated by a boundary, such as a service interface or remoting channel. Then you can version the dependencies independently. Visual Studio will not like having two projects in one solution with the same name, however, so the only way around this is to copy one of the project files, rename it, and load it into the solution.
I've got a legacy project in VS2008 that we're about to start refactoring for better componentization. The references between the 150 projects in the solution are messy, so as a starting point, I'm trying to at least get to a point I can have a few projects use binary references to other projects while others use project references. (For build time reasons)
To Illustrate, given projects A, B, and C, I'd like to see...
A references C.dll
B references C.csproj
Now the problem is I need to make sure that C.csproj builds before A.csproj. I know I can control build order using project dependencies, but this appears to cause exactly the behavior I'm trying to avoid... building A always causes C to build. I'm sure I can monkey with the proj or sln files directly to get things to build in the order I want, but I'm also sure that will get overwritten in short order by VS's automatic magic.
Is there some way to control this order reliably, or am I missing something obvious here?
Thanks...
Separate related components (.csproj) into individual solutions. This enforces binary references across package boundaries. It also forces you and other developers to group components by layer.
Then use your build process to build solutions in correct order starting with the least dependent packages.
In my estimation, from an SCM standpoint Solution == UML Package == Merge Module (all solutions create a merge module)
You could make custom msbuild files instead of relying on the .csproj and .sln files, such that, depending on the target chosen, it will only build certain assemblies. It would require learning msbuild if you don't know it already though.
If I have an assembly (A) which references another assembly (B).
I want to reference A in a project, I add the reference and it copies A into my BIN directory. It does not copy B as well, even though A depends on it, so the code doesn't compile.
How can I set things up so that whenever I reference A, both A and B get copied to my bin directory?
In Visual Studio, add each project to the same solution. Ensure you use Project References instead of direct file references (ie browsing for the assembly).
I dont think there is any way around what you ask other than to explicitly add both. I dont think however adding projects for the sake of getting references copied is a viable solution to the issue. Not all projects that a solution depends on should necassarily be added to the solution. This would completely depdend on your overall project structure, processes, source control, division of labour, etc
Reference both A and B.
Unfortunately you'll have to manually add both. This is what happens to me as well whenever I use pre-3.5 versions of NHibernate: it requires both log4net and Iesi.Collections assemblies. So I have no choice but to manually include a reference to both in all my solutions that implement NHibernate.
This is more of an issue, of course, if you only have the DLLs. If it's a project that you have a codebase to Visual Studio itself will warn you beforehand that the references are missing.
How about adding them to Global Assembly Cache?