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).
Related
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.
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.
In VS2005 I have a few C# projects that depend on each other.
If project A depends on B (e.g. references it), then I want B to build whenever I build A, assuming B has changed in some way since last built. That's the way it is with VC projects, but for some reason it doesn't seem to work with C# projects. If I clean B and then build A it just tells me that it can't find B...
Any ideas?
If you right-click on your Visual Studio Solution and choose "Project Build Order" you can verify the order in which those individual projects are being built. ALSO make sure that you aren't referencing a "debug" DLL in a "release" build and vice versa.
You need to build the actual solution not the projects individually.
A Solution lets you define Dependencies between Projects. And if you use that, it should work automatically. Normally the dependencies are set up automatic too. Chances are you added a reference to the assembly, not the project. Watch the Projects tab in the Add reference dialog.
If you add all the projects to the same solution and set up the dependencies between them then Visual Studio should be able to work out the correct order and build everything that needs building when you change something in one of the "lower" projects.
In your case it would know that it had to rebuild B before building A.
override the target AfterResolveReferences in your csproj. Then use the item #(NonVCProjectReference) to list the path to every project and build them.
I recommend you to read the MSBuild documentation
At the company I work for we have a "Utility" project that is referenced by pretty much ever application we build. It's got lots of things like NullHelpers, ConfigSettingHelpers, Common ExtensionMethods etc.
The way we work is that when we want to make a new project, we get the latest version of the project from source control add it to the solution and then reference the project from any new projects that get added to the solution.
This has worked ok, however there have been a couple of instances where people have made "breaking changes" to the common project, which works for them, but doesn't work for others.
I've been thinking that rather than adding the common library as a project reference perhaps we should start developing the common library as a standalone dll and publish different versions and target a particular version for a particular project so that changes can be made without any risk to other projects using the common library.
Having said all that I'm interested to see how others reference or use their common libraries.
That's exactly what we're doing. We have a Utility project which has some non project specific useful functions. We increase the version manually (minor), build the project in Release version, sign it and put it to a shared location.
People then use the specific version of the library.
If some useful methods are implemented in some specific projects which could find their way into main Utility project, we put the to a special helper class in the project, and mark them as a possible Utility candidate (simple //TODO). At the end of the project, we review the candidates and if they stick, we move them to the main library.
Breaking changes are a no-no and we mark methods and classes as [Obsolete] if needed.
But, it doesn't really matter because we increase the version on every publish.
Hope this helps.
We use branching in source control; everyone uses the head branch until they make a release. When they branch the release, they'll branch the common utilities project as well.
Additionally, our utilities project has its own unit tests. That way, other teams can know if they would break the build for other teams.
Of course, we still have problems like you mention occasionally. But when one team checks in a change that breaks another team's build, it usually means the contract for that method/object has been broken somewhere. We look at these as opportunities to improve the design of the common utilities project... or at least to write more unit tests :/
I've had the EXACT same issue!
I used to use project references, but it all seems to go bad, when as you say, you have many projects referencing it.
I now compile to a DLL, and set the CopyLocal property for the DLL reference to false after the first build (otherwise I find it can override sub projects and just become a mess).
I guess in theory it should probably be GAC'ed, but if its a problem that is changing a lot (as mine is) this can become problematic..