I'm using NDepend to help manage a project and I was just asked to get an ordered list of dependencies (for build ordering of different solutions) based on what was using, both directly and indirectly, a given assembly.
NDepend provides a fine way of finding those modules that are dependent on that assembly, but no way of ordering it in the way I want. For instance I can run
from a in Assemblies
let depth0 = a.DepthOfIsUsing("Assembly1".MatchAssembly())
where depth0 >= 0 orderby depth0
select new { a, depth0 }
and that will get me a list like this
Assembly1 0
Assembly2 1
Assembly3 1
Assembly4 2
Which essentially means that Assembly2 and Assembly3 have direct dependencies on Assembly1, and Assembly4 has a dependency on either Assembly2 or Assembly3.
My problem exists because Assembly3 has a dependency on Assembly1 AND Assembly2. And if Assembly4 only had a dependency on Assembly 2, I'd like to see a list like this:
Assembly1 0
Assembly2 1
Assembly3 2
Assembly4 2
If Assembly4 also had a dependency on Assembly3, then the list should look like this:
Assembly1 0
Assembly2 1
Assembly3 2
Assembly4 3
Now I can export the original list to a dependency graph, and view it horizontally, and manually fill out that dependency list myself, but I've actually got 123 assemblies in my hierarchy and that's a hell of a job, especially when I have other processing to do after that (something I know can't be achieved with NDepend), so I'd rather find a way of do this in CQL.
Anyone with ninja NDepend skills know how I can achieve this?
Thanks.
Related
I have an application A that depends on library B. But library B can only build for the target, i.e. non-native. Also, I need to build A for both the host and the target. Unfortunately, I get an error like this:
Nothing PROVIDES B-native (but A-native DEPENDS or otherwise requires it)
In the recipe for A, I have tried numerous variations of
DEPENDS_append = "B" DEPENDS_remove = "B-native" DEPENDS-${PN}-native_remove = "B-native"
to no avail.
I'm sure there is a simple way to do this but I haven't found the correct combination of commands yet.
i have added dependencies through DEPENDS +=. While do_prepare_recipe_sysroot, what order does it follow while copying to recipe-sysroot?
How I can enforce this order?
eg:
for recipeA
DEPENDS += "recipeB recipeC"
DEPENDS += "recipeD"
where as recipeB depends on recipeD.
Here recipeC and recipeD both populate header.h. which one will be include in the recipe-sysroot.
You can't do this. Dependencies ordering is automatically done by Yocto. Same file cannot be provided by different recipes. You will get error like below,
Exception: FileExistsError: [Errno 17] File exists:
So you need to fix up the path. For example, if recipe C is for Application X, then you should try usr/include/X/header.h and usr/include/Y/header.h for recipe D or you should name is differently.
As far as dependency is concerned, you don't need to worry about the ordering. Yocto automatically parses and identifies which one to compile first in it's task queue.
I have decompiled 2 .net 2.0 dlls (using a decompiler tool) and when I compare a function both are same. But when I compare these 2 assemblies, ndepend shows difference in ILInstructions and NBLinesOfCode.
Please let me know why ndepend is showing the function difference but decompiled code is same? if having differences (IL Instructions and LOC) in ndepend means the functionality is really different for 2 dlls?
What steps I can take to make the 2 assemblies same so that ndepend doesn't show difference in that function?
Please note I have lost original source code and I am trying to re-build the source code to make it original dll.
In sbt, if I use mapR on the compile task, I can get an Analysis object that will let me harvest warnings and other information. This allows me to keep track of project-specific warning statistics programmatically.
However, I have many subprojects aggregated under a root project, using sbt's aggregation functionality. Is there an idiomatic way to aggregate this information (or arbitrary information) up an aggregation tree like this? For example, if I wanted to know the total number of warnings in the entire build, how might I do that? I can maintain global Scala-level state within my sbt project and add to an AtomicInteger after each project's compile step, but that feels ugly and I feel like there must be a better way.
For context, I want to tell TeamCity the total number of warnings in the build, so I need to be able to aggregate information like this.
There is a straightforward way that is specific to getting the Analysis, but only if all of the Analysis values that you want are on a classpath.
In sbt, a classpath has type Seq[Attributed[File]].
The Attributed part attaches metadata to each entry.
One piece of metadata is the Analysis for that entry (obviously only if it was compiled from source).
So, this would get a Seq[Analysis] for a classpath:
... (fullClasspath in Compile) map { (cp: Seq[Attributed[File]]) =>
cp.map(entry => Defaults.extractAnalysis(entry)._2)
}
Note that the implementation of Defaults.extractAnalysis gets an empty Analysis if there isn't one attached.
In 0.13, there is finally an API for doing this generally:
http://www.scala-sbt.org/snapshot/docs/Detailed-Topics/Tasks.html#multiple-scopes
In this case, it would look like:
someTask := {
val allA: Seq[inc.Analysis] = compile.result.all(
ScopeFilter( inAggregates(ThisProject), inConfigurations(Compile) )
).value
...
}
(The result part does the same as mapR in the direct syntax:
http://www.scala-sbt.org/snapshot/docs/Detailed-Topics/Tasks.html#result
)
So I have my project and it is set up like this:
MyProject
MyProject.Module1
MyProject.Module1.Tests
MyProject.Module2
MyProject.Module2.Tests
What I want is the code coverage number for the entire project.
I am using nCover... what is the best way to do this? For example would I have to rearrange the project and have everything put into MyProject.Tests?
It depends on how you're testing. Most test frameworks will let you run tests for multiple assemblies as separate arguments. If you can't run them all together, you can always use NCover's merge feature. Check out http://docs.ncover.com/ref/2-0/ncoverexplorer-console/merging-coverage-data/.