I am using Ndepend to find out what third party DLL's are needed for my application
This is a screenshot of missing dependencies. From the right side of the screenshot there are some red x's. Can someone help me or point me to where I could find 'Why is this DLL needed? Or which assembly references these. Find all the references for these missing dependencies'
This not found DLL (in the blue grid, third-party assembly) is needed because it is referenced by a DLL in the green grid (application assemblies).
If you run the analysis from there, you'll get warning logs like assembly XYZ is referencing DevExpress.ExpressApp.v.. version ABC that cannot be found.
You can unfold the Directories manager just above the green grid, to add folder(s) that contain the DLLs not found.
Related
I added a reference itextsharp.dll to my plugins project, when running my plugins using plugin-registration tool I get this exception:
Could not load file or assembly or one of its dependencies. The system
cannot find the file specified
I tried removing the ref and adding it again, cleaning and then adding it to my project from different places.
Is there restrictions in plugin registration tool about adding non crm dlls? why ? how to solve it?
This is not going to work - you cannot reference external assemblies from CRM plugins that are registered in database. If you want to do this, you will have to merge your external dll with your plugin assembly. You have to remember that adding assembly as reference is not automatically making your referenced assembly available for your base assembly, therefore if you register your plugin assembly in CRM, system is not going to "magically" find somewhere your external assembly (in your case - "itextsharp.dll"). If this is not Online system, you can add your assembly to GAC, or register all your assemblies on Disk instead of database (not recommended approach). If you want to register them in database, you will have to merge everything in one assembly using ILMerge for example.
You can't reference something in a plugin unless it's in the bin of the CRM.
To make it work you need to ILmerge your reference with the plugin. Install this package in your project: MSBuild.ILMerge.Task. Then build. It will work instantly. The package will merge everything in the bin after the build. So make sure every other references are marked "Copy Local = false". Otherwise, you'll have a crazy big assembly.
Finally, Microsoft released a solution for this. You can build a nupgk file and register dependent assemblies.
Here are the white paper and my post about this;
Microsoft : Microsoft White Paper
My summary: Here is the link
I want to create a documentation via sandcastle.
Therefore I need to reference DevExpress which should not be documented.
I added the DevExpress dll's under references and the DevExpress resource folder at the project, too.
I tried several different settings, but can't resolve it.
Now Sandcastle shows this Warning several times:
BuildAssembler : warning : ResolveReferenceLinksComponent: [T:test.DEVEXPRESS] Unknown reference link target 'P:DevExpress.XtraEditors.BaseStyleControl.Appearance'. [G:\test\test\test\Testing\Working\BuildReferenceTopics.proj]
How can I resolve this?
I've been facing the same issue for a while now, and I'm just getting around to researching it.
Sandcastle builds documentation which contains clickable reference links. However some references may not resolve because
they are from external assemblies (dependencies). This will cause a warning in the build output. If you're OK with that then just ignore it because there's no harm. However if you have OCD (like me), then follow the instructions below to suppress the warnings.
Instructions
Create a dummy Sandcastle project.
It does not need to be included in the solution, however I find it helpful during the setup.
Disable the project from being built. (Recommended as the build may fail.)
Add the assemblies mentioned in the ResolveReferenceLinksComponent warning to the Documentation Source.
Try to build it. It may fail with "unresolved assembly" errors. (Perhaps dependencies of your dependencies.)
If the "unresolved assembly" is not reference directly in your project then you can ignore it using the Assembly Binding Redirection plug-in.
Otherwise add the required referenced assembly to Documentation Sources as well.
You can also add it to the project References.
Add the dummy Sandcastle project to the main Documentation project using the Additional Reference Links plug-in.
Make sure to configure the plug-in so that all Link Types are set to None.
Note: When updating dependencies, the dummy Sandcastle project's Documentation Sources and reference also need
to be updated. [TODO]: Find a way for this to be automated. Nuget?
Note: Sandcastle does a partial build of the dummy project to gather Type information (via reflection). The dummy project
does not necessary have to build successfully however it must pass the TransformReflectionInfo phase in order for the plug-in to work.
References
GitHub Issue #67
Documentation Q&A
Additional Reference Links Plug-In
Assembly Binding Redirection Plug-In
IMO this is not quite the solution I was hoping for as it adds another project needlessly, however since I had so many warnings that they were masking real issues. Better of two evils I guess.
Using the really easy to follow instructions for building a NuGet package for an assembly with an associated package of sources for the symbol server, found here on David Ebbo's blog "The easy way to publish NuGet packages with sources" I have indeed created a pair of packages: binary and sources.
However, the sources package is incomplete and the reason is that the sources come from two class library .csproj and I used ILMerge to combine the results of the second into the first. (*) So, using the minimal .nuspec described in this post and pointing nuget.exe at the .csproj for the "main" library, the binary package is fine, but of course the sources package only has sources for the "main" library, not also for the library that was ILMerged into the "main" library.
How do I fix this (and get the sources for both projects included in the symbol package but only the binary for the "main" project in the binary package)?
FYI, the actual nuget.exe command line was: nuget pack CommandLineLexing.csproj -Build -Symbols -Properties Configuration=Release.
(*) The reason I'm doing this, in case you're interested, is that the second library is a cut down version of my accumulated "C# utilities" library - you know, a bunch of extension methods and other helpers - cut down so it only has the bare minimum needed for this particular project. And so, since it is cut down, I don't want there to be separate assembly for it which might eventually get confused with the full assembly (having the same name, and not a strong name). So I used ILMerge to put the utilities methods into the main assembly (and also mark them internal).
Not going to be easy I'm afraid.
NuGet symbol packages are simply your regular package, with pdbs, augmented with source files.
Assuming you already know you can get a merged PDB with ILMerge/ILRepack (/debug), that part is probably working file, I'm assuming your issue is that only the source files from the current project gets included.
You could simply post-process your symbol.nupkg (which is a zip), and include the source files from your other (merged) project in the src folder (you can even try that manually).
Though if you run srctool.exe -r MyMergedAssembly.pdb, you'll see different root paths, where usually (for a non-merged project) they all have a common prefix.
It may work, if SymbolSource copes with having multiple path prefixes in your PDB, that I haven't tried.
I also failed to find any documentation irt to their processing of symbol packages. We can assume they use pdbstr.exe tool to update the PDB srcsrv section of the PDB file to redirect the symbol loading to their website, but one can only tell if they support multiple roots by testing it.
If you upload your augmented symbol package to symbolsource, you can download the updated PDB using a URL similar to http://srv.symbolsource.org/pdb/Public/Castle.Core.pdb/4C81FC30DF584853B9869EAB2FA7D9891/Castle.Core.pd_ (then unzip it to a pdb file)
Then you can use both srctool.exe file.pdb and pdbstr.exe -r -s:srcsrv -p:file.pdb to verify their work.
Background: I have two assemblies called "A" and "B". ""A" references "B". "A" also references some additional dll's (Microsoft.Enterprise Library.Data and Microsoft Enterprise Library.Common ) that I think should be packaged in the nupkg.
I believe my nupkg package should contain the assembly output from "A", "B" and the two "Microsoft Enterprise" assemblies so that when someone installs my package it will give them a direct reference to the Assembly "A" and the other three assemblies would be available (but not directly referenced, so that their app would run. What is the correct way of packaging the non references dlls?
Attempt #1: Packing all required dll's in a \net35 folder
According to the NuGet documentation regarding the "references" element "If this element is omitted, then the usual behavior applies, which is to reference every assembly in the lib folder."
So, I assume that by using this element it will only include the assemblies specified as references. This does not seem to be the case if I also use a "file" element <file src=*.dll" target="lib\net35" />. If I have an element like this that copies all dll's to the package it results in the assembly that implements this package to reference ALL the assemblies in the \net35 directory. This is not what I want to do. I expected some magic that only the assembly specified in "references" would be an actual be referenced and all the others would remain in the exploded \packages folder and the app would work since all the dlls are located in the same directory. Maybe I'm incorrect....
Attempt #2 Adding as content to project
If I place the unreferenced assemblies into \content\lib instead of lib\net35 when packaged this creates a \lib folder in the project and directly dumps the \content\lib dlls into that project which then forces us to check them into source control. This works, compiles and runs as I want but, I really don't want these stored in the \lib folder of the project.
I am looking for a solution where the project gets the references to "A" and can still run with the to other required assemblies co-located but not directly referenced. It seems like Attempt #1 is the correct path but maybe there is a bug?
FYI, I entered this as a issue with NuGet directly to see it that team has an answer as well.
This was a bug introduced in Nuget 2.1 and was later fixed in Nuget versions 2.2 which was released in December 2012.
Using Attempt #1 in original posting now works correctly.
I don't think your "Attempt 1" is going to work in practice. If you only reference "A". when you build your package, only "A" will be copied (by default) to the output directory. Then, when you distribute the application, only "A" will exist causing errors.
You should have references to all DLLs to make your application run (or come up with another solution that will automatically copy the referenced DLLs to the output directory, but I'm not sure there is much value in not specifying the reference directly). Since you only have a few DLLs, it is probably best to just leave out the references section so that all of the DLLs are referenced automatically from the lib folder.
I have a VSTO addin, which works fine. I am trying to give it a plugin-loading mechanism so that others can add plugins to my plugin. I sounds horrific, I know, but it seems to best option for now.
I publish my addin to a folder called 'Published'. This creates the application manifest (Symbols.application) and also a folder called Symbols_x.y.xx.yy with the actual addin assemblies in it. Visual Studio increments this version number each time I publish, so the assemblies are never in the same place twice.
The plugins are in a folder Published\Plugins. I load the plugin assemblies using Assembly.LoadFile(string) and this works OK. The plugins are all in folder which stays in the same place no matter how many times I publish it and I can scan that folder for DLLs and load them.
What doesn't work is when those plugin DLLs have dependencies. In particular, one depends on a COM object. Visual Studio builds an automatic Interop DLL which it puts in the Published\Plugins folder, alongside the corresponding plugin DLL. An exception is thrown as soon as any attempt is made to access the COM object, saying that the interop assembly could not be found.
Putting the interop DLL into the folder Published\Symbols_x.y.xx.yy folder works, but that requires manually putting it there each time. I've tried adding the plugins to the AppDomain's PrivateBinPath, but the documentation says that anything outside the ApplicationBase will be ignored and it seems this is indeed the case - it doesn't work. ApplicationBase is set to Published\Symbols_x.y.xx.yy.
It seems to me I have four options:
Figure out how to change the ApplicationBase, moving it up one level, and then add the Published\Plugins folder to the AppDomain's PrivateBinPath.
Make some change to the application manifest to indicate that assemblies can be loaded automatically from Published\Plugins.
Find some other way of explicitly loading an assembly into the AppDomain, not just into memory using Assembly.LoadFile.
Anything else anyone wants to suggest!
But I can't find any way to get any of these options to work. Help!
The solution was provided by the MSDN forums:
I've added an event handler to AppDomain.CurrentDomain.AssemblyResolve. This gives you a chance to load the assembly in whatever way you like, including by loading it from my plugins directory.