I was able to do this in an earlier version of nDepend by going to tools->options and setting which assemblies would be part of the analysis (and ignore the rest). The latest version of the trial version of nDepend lets me set it, but it seems to ignore the setting and always analyze all assemblies whether I want it to or not. I tried to delete the "tier" assemblies by moving them over to the "application assemblies" list, but when I delete them out of there, they just get added back to the "tier" list, which I can't ignore.
I don't want my dependency graph to contain assemblies like "system," "system.xml," and "system.serialization!" I want only MY assemblies in the dependency graph! Or is that a paid-version feature now?
Is there a way to do what I'm talking about?
If you are talking of the live graph in the UI, in the Dependency Graph panel, to remove third-party assemblies there is the menu Reset (top-left icon) >>> Reset to application assemblies only
If you are talking of the graph in the report, just tick the box NDepend Project Properties >>> Report >>> Assemblies Dependency Graph >>> Hide third-party assemblies
Related
In MS Dynamics CRM how do we register a plugin or a workflow as part of a solution? whatever i register through registration tool, just goes to the root solution of the system.
Expanding on what #Henrik said, the process would be as follows.
For the sake of this example, let's assume you have a single assembly (dll) with two plugins and each needs two steps.
Register the assembly as usual with the Plugin Registration Tool.
For each of the two plugins, register the two steps they require. This should leave you with four in total.
Leave the Plugin Registration Tool and go to your solution in CRM. You will see two sections there: Plug-in Assemblies and Sdk Message Processing Steps.
You will need both of these to fully register a plugin with your solution.
Go to the Plug-in Assemblies section and use the Add Existing button. This will bring up a standard lookup dialogue that will let you select your assembly. Add it.
Next, go to the Sdk Message Processing Steps section and use the Add Existing button to add any plugin steps you want as part of the solution.
That's it. Your assembly, plugins, and steps are now part of the solution. Any step images that may exist are automatically added as part of the step so no need to worry about them.
One caveat though is that assemblies must be stored in the database and not as files for this to properly work. There is no specific limitation on sandboxed plugins (unless deploying to CRM Online) but using those would simplify solution deployment.
Finally, this walkthrough which was taken from the How To button in a solution.
Walkthrough: Register a plug-in using the plug-in registration tool
As for workflows, they need to be added in the Processes section of a solution. This section will cover workflows, dialogs, business process flows, and actions. As before, use the Add Existing button.
There is no direct support for adding plugin assemblies or plugin steps to solutions when registering with the Plug-in Registration Tool.
Your plugin steps and assemblies will always be present in the layer of unmanaged customizations ("root solution").
You can use the Plug-in Registration Tool as usual and only later manually add your assembly and steps to the relevant solution(s).
Is it possible to embed code coverage results (stored in SonarQube) into Github projects as one of those embeddable icon gadgets (not sure what their name is; it would be great if somebody to tell me that as well)...? I'm referring to the ones that show the build status, for example.
The only thing currently available is this under-development plugin, which was first discussed in this Google Group thread. Note that this project appears to be in its infancy.
EDIT
This plugin has since been released, and can be installed directly from the Update Center
EDIT 2
With SonarQube 7.1, badges become a native feature.
Using a plugin in no longer needed, as some new APIs are now added that will do what you want. You can use this snippet in your .md files:
[](https://{domain}/component_measures/metric/coverage/list?id={projectName})
Note that you have to replace parameters inside {}s with your own values. If you are using on-premise version, the domain will be your own domain and if you are using cloud version, it will be sonarcloud.io.
Also note that this will work only for public projects. For private ones, I could not find any solution.
And finally as a side note, the metric parameter takes some values other than coverage and gives other fantastic badges that you may find helpful:
bugs, code_smells, coverage, duplicated_lines_density, ncloc, sqale_rating, alert_status, reliability_rating, security_rating, sqale_index, vulnerabilities
BACKGROUND
As time goes by, I find myself more and more turning to NDepend to gain insight into the design/implementation of legacy applications.
QUESTION
Rather than adding JustMyCode to CQL queries, is there a way to permanently configure NDepend (at the project level) to simply ignore the .NET Framework? I could be wrong, but I am pretty sure that this feature was supported by NDepend v3.
EXAMPLE
Open your solution in Visual Studio and click Rebuild
create an NDepend project based on your solution file (*.sln)
run the Analysis
open the interactive (non-HTML) Dependency Graph
click the Reset arrow in the top left corner (hint: the recycling icon)
click reset to application assemblies only
observe
you will no longer see references to the .Net Framework (note: the blue writing is gone)
right click on one of your assemblies: Select Types
click that I use directly
the following CQL will appears in the queries window:
from t in Types where t.IsUsedBy ("MyCompany.MyProduct.MyAssemblyName") select new { t, t.NbILInstructions }
observe
more than likely you will now see .NET Framework references (note: the blue writing is back) in the query results window
add JustMyCode to the CQL query and the .NET references disappear again: from t in JustMyCode.Types where t.IsUsedBy ("MyCompany.MyProduct.MyAssemblyName") select new { t, t.NbILInstructions }
CONTEXT
Application: NDepend version 4.1.0.6871
View: Dependency Graph
The only two ways to ignore a .NET assemblies are:
Using notmycode/JustMyCode as you wrote
Remove the assembly from the Project Properties > Code to Analyze panel.
I am looking for a way to colorize entries in Eclipse' Package Explorer:
In bigger projects you have dozens of files in a package all listed underneath each other. This makes it hard to find the file you look for (e.g. for right-click operations). So it would be nice if I could manually colorize some entries.
Does a plugin for this exist?
This is one that I was using before. It lets you set rules and tints icons accordingly:
Label Decorator
One way to have Eclipse filter the classes you see is to use Eclipse Mylyn. You create tasks that you work on and Mylyn will remember the packages and classes associated with a certain task. It will then filter out all other classes/packages. This gives you an editor that only shows the information relevant to a specific task.
I suggested Mylyn for a different problem aswell and in that answer I gave a bit more information.
We're looking into setting up a proper deployment process.
From what I've read there seems to be 4 methods of doing this.
Copy & Paste -- We don't want to do this
Using the "Package" mechanism built into the Salesforce Web Interface
Eclipse Force IDE "Deploy to Server" option
Ant Script (haven't tried this one yet)
Does anyone have advice on the limitation of the various methods .
Can you include everything in a Web Interface package?
We're looking to deploy the following items:
Apex Classes
Apex Triggers
WorkFlows
Email Templates
MailMerge Templates -- Can't seem to find these in Eclipse
Custom Fields
Page Layout
RecordTypes (can't seem to find these in Website or Eclipse)
PickList items?
SControls
I recommend the Force.com Migration Tool.
For reference:
Force.com Migration Tool Documentation
Migration Tool Guide
The Migration Tool allows you to use ant targets to move your metadata between salesforce.com organzations.
I can speak to this from recent painful experience.
Packaging: this is a very old method that predates the metadata API on which both Ant and Eclipse rely. In our experience, packaging's only benefit is in defining your project. If you're using Eclipse (which we do, and I recommend), you can define your project as being based on a particular package. As long as you remember to add new components to your package, your project hangs together
One thing that baffled us for a while, btw, are the many uses of package. We've noted the following:
Installed packages: these come in managed and unmanaged flavors and are really, in the words of a recent post on the SFDC boards, for ISVs to deploy their stuff into various unknown orgs "out there". Both managed and unmanaged packages have limitations that make them unsuitable and unneeded for deployment from development to production within an org, or in any case where you're doing custom development and don't intend to distribute code to a large anonymous base.
Non-installed packages: this is what you see when you click "Packages" in the web UI. These, that we sometimes call "development packages", seem to be just a convenient way to keep a project definition together.
Anyway, the conclusion I'm coming toward is that our team (custom development, not an ISV) does not need packages in any form.
The other forms of deployment, both Eclipse and Ant, rely on the Metadata API. In theory they are capable of exactly the same things. In reality they appear to be complementary. The Force.com migration tool, built into the Force.com IDE for Eclipse, makes deployment as easy as it can be (which is not very) and gives you a nice look at what it intends to deploy. On the other hand, we've seen Ant do some things the IDE could not. So it's probably worthwhile to learn both.
The process we're leaning toward is to keep all our projects in SVN, and use the SVN structure as the project definition (Eclipse will work with this and respect it). And we use Eclipse and sometimes Ant for migration. No apparent need for packages anywhere.
By the way, one more thing to be aware of -- not all components are migratable. Some things must be reconfigured by hand in the target environment. One example would be time-based workflows. Queues and Groups also need to behand-created, I think. Likewise the metadata API can't directly process field deletions so if you deleted a field in your source, you need to delete it by hand in the target. There are other cases as well.
Hope that's useful --
-- Steve Lane
As of Spring '09, mail merge templates are not supported in metadata but record types are. You will find record types as an XML element in the file for the object they belong to. Everything else on your list is supported with a small exception. Picklist values for standard fields cannot be edited in Spring '09. Stay tuned for news on Summer '09 feature announcements.
Update: Standard picklists on standard objects are now metadata exposed (as of API v16):
http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
Otherwise, Steve Lane's response is pretty accurate. The advantage of using unmanaged packages (what Steve calls non-installed packages) is that when you add metadata to a package, the metadata it depends on will automatically be added. So it's easier to grab a full set of metadata containing all its dependencies. If you are repeatedly moving metadata from one org (sandbox) to another (production), Steve's approach is probably the best way to go and certainly the most common today. I frequently use unmanaged "developer" packages to move something I've developed in one org to another unrelated org. For my purpose, I like to have the package defined in the org as opposed to an Eclipse project / SVN. But that probably doesn't make sense if you are doing team development across many dev/sandbox orgs and are using SVN already.
Jesper
Another option is to use Change Sets if you want to move meta data from a sandbox to production.
There are currently some limitations on how change sets can be used:
Sending a change set between two organizations requires a deployment
connection. Currently, change sets can only be sent between
organizations that are affiliated with a production organization, for
example, a production organization and a sandbox, or two sandboxes
created from the same organization.
From the docs:
A package must be managed for it to be published publicly on AppExchange, and for it to support upgrades. An organization can create a single managed package that can be downloaded and installed by many different organizations. They differ from unmanaged packages in that some components are locked, allowing the managed package to be upgraded later. Unmanaged packages do not include locked components and cannot be upgraded. In addition, managed packages obfuscate certain components (like Apex) on subscribing organizations, so as to protect the intellectual property of the developer.
Advantage to managed package would be that it allows you to easily version and distribute things across multiple SFDC organizations.