On my current project we are using Nuget to bring in dependencies on things like NHibernate, we use Ninject as our IoC container (although that's not an important detail of the problem I'm trying to solve) and we use Ninject's scanning functionality for establishing our bindings.
This all works fine but the problem that I'm facing is that I've gone through the trouble of making my Data Access Layer be exposed to the Application Layer in a Presistence Ignorant fashion but Ninject needs to have access to the NHibernate Dlls at scan time. If I wasn't using Nuget to pull in dependencies then this could easily be solved with a post build step to copy the dependencies from wherever I had decided to put them in my source tree.
However, with using Nuget my understanding is that the path to Dlls could change in the package directory as dependencies are upgraded. I definitely don't want to solve this problem by using Nuget in my Coposite Root projects (services, UX, etc...) and so I'm trying to figure out a clean way to get the dlls that I need at scanning time available in my Composite Root projects execution directories.
Related
I am in the processing of integrating Maven into my my projects. While maven has plenty of pros i'm finding it difficult to figure out how to maintain my current development process, which is as follows:
For creating SDKs I will create a sample app, which will depend on and directly reference the SDK source code, all from within the same code project. This means that I can make easily change/debug the SDK code with one click run/debugging.
I fear this won't really be possible with Maven. Can I create some type of Hybrid approach, where I continue my normal development approach and then push builds to Maven when it is appropriate.
Update - For Clarity
My problem is that when everything is done through maven, the dependencies are built and published to Maven. Then, the dependent project pulls down compiled references and uses them. My issues is that I don't want to go through this whole process every time I make a small change to a dependency.Thanks.
You should try creating parent level pom.xml with two modules - your library and simple app to test it. In simple app's pom.xml provide a dependency on library module.
Then open in your IDE parent pom as maven project. This should be sufficient for normal debug.
Other possible approach - install you library artifact into maven repo with sources. In this case you will be able to debug it, but test app still have to load use jars from repo.
There have been many posts on this topic, but I have yet to find the "real" solution.
How does one manage their dependency tree (both compile time and runtime) using MSBuild project files (i.e. Visual Studio project files via project and file references)?
It is well known that project references from child projects will not be copied to an application bin directory if there is no compile time reference, even if there is a runtime dependency, and even if copy-local=true. Hence, any loosely coupled component will not be copied over.
The hack to solve this problem is to include the dependency in the parent project with copy-local=true. However, this basically destroys your dependency tree as you no longer know where the dependency is and ultimately, as your app grows and morphs, you end up with a version of DLL hell. Your parent project ends up with 10s to 100s of dlls, most of which are runtime dependencies of dlls in child projects.
Another hack is to write a custom targets file and call it from every project file: http://blog.alexyakunin.com/2009/09/making-msbuild-visual-studio-to.html. But surely there is a better option. This is such a bread and butter thing. Java devs never have to deal with such trivial issues.
From what I can gather, the Microsoft way to solve this problem is to register every dependency in the GAC for every dev, test and production machine. But this is stupid and annoying. I won't bother giving this option and educated rebuttal.
Avoiding the GAC option, how could one use MSBuild to manage a dependency tree that includes runtime only dependencies? How does Microsoft do it? Surely they don't run custom targets files like the one in the link above.
I hope someone from an enterprise .NET background can step up and offer some real advice on this. Otherwise I'm just going to have to rewrite all my build scripts in NAnt (shudder).
Thanks All.
UPDATE
In response to some comments, the following is a practical example of the issue from my current project.
The app is a Web Application project that exposes a suite of WCF services. It has an external domain DLL containing the external service classes and an internal domain DLL containing internal service POCOs, domain objects and DAOs. There is a separate integration DLL containing interfaces (DTOs) for all the internal domain classes that allows us to completely decouple the external and internal domains. The whole thing is wired up with Spring.net. I hope this is clear, let me know if you need more clarification.
My current build process is to use MSBuild to generate a deployment package for the web application (in TFS Build). So while the whole solution is built initially, only the output from the web application gets packaged. Therefore, the Web Application is treated as the dependency root and I expect that any loosely coupled child references should get copied over on build if they are set to 'copy-always=true'.
So the Web Application contains a reference to the external domain DLL which contains a reference to the internal domain DLL which contains many references to 3rd party libraries and various indirect and loosely coupled dependencies required by the 3rd party libraries.
The problem occurs when there is a 3rd party dependency in the internal domain DLL e.g. oracle.dataaccess which is required by NHibernate at runtime. Even when I set 'copy-always=true' on these DLLs, they do not get copied to the Web App package. The only way I can include them in the package is to add these DLLs to the Web App's references. I don't want to do this because I no longer have a meaningful dependency tree.
I hope this makes the issue clearer. Please let me know if anything is unclear. It's hard to describe this sort of stuff.
If anyone is also having a similar issue, please speak up and share your experience.
I really want to give you a better answer but unfortunately you didn't put enough information about your solution/projects and your dependencies, so I will try to give you several ideas and I hope one of them works.
The easiest thing to do as you said is to set up a separate folder with all of your dependencies and create target file that will copy them to your bin folder. If you have dependencies that are not changing frequently that might work. If another team from your company is building them and they change frequently, this approach is not good.
Another simple approach - if you're referencing your dependencies from your solution only you can change the build path, so that they build directly into the bin folder of your main project. This way you don't have to reference them directly.
Use NuGet. You have a separate team producing loosely coupled dependencies it may make a sense to set up local NuGet repository and use it for that http://juristr.com/blog/2012/04/using-nuget-to-distribute-our-company/
I hope that helps.
I created 2 dummy projects in my application and named them BAL and DAL. When I build them, they build successfully. If I add a reference to BAL to the DAL project, it added nicely. But while adding the DAL reference to the BAL project, I get the following error:
A reference to DAL could not be added. Adding this project as a reference would cause a circular dependency.
Can anyone help me to solve this error?
Here's what you need to do:
Right click on the DAL Project in the solution explorer and select Project dependencies in the context menu.
You will now see a window that shows the project dependencies of the DAL Project. Make sure that BAL isn't checked.
Now you should be able to add your reference...
I hope this helps I've tried to keep it as simple and straight forward as possible.
Explanation:
Your DAL should not be able to access the BAL. Your code reference dependencies should be like this:
MVC project -> BAL -> DAL
The MVC project should reference the BAL, the BAL should reference the DAL. Set up your project like this. Make it work and then you will better understand why this setup is better.
Given:
Data = raw numbers and strings
Information = processed data into something meaningful
Cosider the following:
The UI should get its information from the BAL which could be able to compose it's data based on the DAL.
You can only reference in one way otherwise you get the error like you said. Just do this: delete the reference from your DAL to your BL and make a new one from your BL to your DAL!
It is implicit in the concept of "layers" that higher layers depend on lower ones, and not the other way round. If 2 "layers" are mutually dependent, then one is not higher than the other, they are not layers in any meaningful sense, and so can be considered to be in the same layer. The same basic principle holds for architectural components or modules, as enforced by Studio for project dependencies. If you use this principle - think of your projects as design modules rather than e.g. just throwing everything into a single project - you will have well-structured codebase which will give you far less problems as it grows in size.
That would cause a circular dependency. What you perhaps want to do instead is have a main application project, which references the BAL, and then BAL referenes DAL.
Data access should not need to reference business logic.
This just happened to me. You have a circular dependency, i.e. two projects both referencing each other. You need to make one of them independent of the other. Takes some time and it happens so quick. One second I was happily coding along, and the next I had 45 errors like this. Just took some time but it makes your architecture/program structure better too, helping you sort out dependencies properly.
Occasionally, you have two different projects, each of which needs methods that the other has. In this case, you can either make a third project and move the shared code into there, or choose one of the two projects to put the shared code in.
This problem occurred to me when I was building a WPF application with several layers like repository interface layer, repository service layer, sql service layer, rest service layer and my main WPF UI layer.
I resolved this error. I noticed that some of the layers were
unnecessarily referencing other projects. I removed this unnecessary
reference.
Then I noticed that some of my service layer and repository layer
had my WPF UI project as reference(My StartUp project); this is
what was creating circular reference. I removed this.
========================================================================
Conclusion: Check each projects reference dependency and make sure there are no unnecessary reference. Make sure sub layers are not referencing the startup project in the reference.
Hope I was helpful.
In my case I copied a project file without generating a new ProjectGuid. Since Visual Studio uniquely identifies projects using the ProjectGuid, it assumed the project was trying to reference itself.
in my case the project was somehow already declared in refrences in csproj.cs in the targeted project so simply i removed all the dependency in csproj.cs and tried to add from main project again and it worked
I had two projects called Application and Persistance that the reference of the Application project to the Persistance project encountered a circular dependency error.
By clicking on the Application project and looking at the values used inside it, you will notice that the Persistance project is include inside the <ItemGroup> tag, which is why you receive a Circular Dependency error.
To fix this error, just Comment this Include.
To get around this, add the reference by browsing to the projects DLL after it has been built. Do not select it from the "Projects" tab.
Trying to build Spring-based application one needs to figure out all necessary dependencies the application will have.
For example, I was using HibernateTemplate, and each time I run the application the ClassNotFound exception comes out. So I “google” for jars that contains this particular class, after search mvnrepository to find appropriate artifact. Always confuse about which version to use.
And it’s happened again and again, and only after few hours and few dozens of dependencies added the application become runnable.
But even after that, I tried to use my app. on different computer with slightly different parameters, and slf4j class not found error appeared, even after testing extensively on the developer machine, still some dependencies missing.
Now it works fine, but I want to distribute my application, and not sure if on another system there will no dependency missing.
So, what is the best practice to determine all necessary dependencies not only at design time but in runtime too? Is there any tool for that?
How one can manage versions confusion, when there are dozens of dependencies each with its own version?
They both resolve dependencies, so you keep a dependency file and it does all the heavy lifting of making sure everything is included in your builds. Use the full spring dependency list. I had problems with SLF4J too.
http://mvnrepository.com/artifact/org.springframework/spring-full/1.2.8
I'm using Castle Windsor to do some dependency injection, specifically I've abstracted the DAL layer to interfaces that are now being loaded by DI.
Once the project is developed & deployed all the .bin files will be in the same location, but for while I'm developing in Visual Studio, the only ways I can see of getting the dependency injected project's .bin file into the startup project's bin folder is to either have a post-build event that copies it in, or to put in a manual reference to the DAL project to pull the file in.
I'm not totally thrilled with either solution, so I was wondering if there was a 'standard' way of solving this problem?
Could you set the build output path of the concrete DAL project to be the bin folder of the dependent project?
Mike: Didn't think of that, that could work, have to remember to turn off copy-local for any libraries / projects that are common between them