{"id":23025,"date":"2016-10-07T17:03:54","date_gmt":"2016-10-07T21:03:54","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/?p=23025"},"modified":"2019-02-14T15:56:15","modified_gmt":"2019-02-14T23:56:15","slug":"live-architecture-dependency-validation-in-visual-studio-15-preview-5","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/live-architecture-dependency-validation-in-visual-studio-15-preview-5\/","title":{"rendered":"Live architecture dependency validation in Visual Studio \u201c15\u201d Preview 5"},"content":{"rendered":"<p>In the past year, you told us that you considered removing unwanted dependencies to be an important part of managing your technical debt. The <a href=\"https:\/\/msdn.microsoft.com\/en-us\/library\/dd465141.aspx\" target=\"_blank\">Layer designer<\/a> enables you to validate architectural dependencies in your Visual Studio solutions. It first shipped in Visual Studio 2010, and is now part of Visual Studio Enterprise. But the experience could be improved. So, in Visual Studio \u201c15\u201d Preview 5, we are introducing a new <b>Dependency Validation<\/b> experience to help ensure that you, developers, respect the architectural constraints of the application as you edit your code.<\/p>\n<p>Before presenting the new experience, let me first recap what the experience is in previous versions of Visual Studio Enterprise (Layer diagrams).<\/p>\n<h4>Previous experience: Layer validation in Visual Studio 2010-2015<\/h4>\n<h5>Layer diagrams express architectural constraints<\/h5>\n<p>The screenshot below shows Visual Studio 2015 Update 3, where a layer diagram expresses the allowed dependencies between four layers. The blue rounded rectangles are layers associated with code elements; for example, here they represent assemblies, but they could be any set of code elements. The arrows express the permitted dependencies. You can also express additional constraints on each layer related to namespaces. For example, a property \u201cForbidden Namespace Dependencies\u201d here indicates that the UI layer (selected on the diagram) should not depend on Owin (in the property window).<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/05\/clip_image0013.png\"><img decoding=\"async\" width=\"797\" height=\"806\" title=\"clip_image001\" style=\"padding-top: 0px;padding-left: 0px;padding-right: 0px;border-width: 0px\" alt=\"clip_image001\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/10\/clip_image001_thumb2.png\" border=\"0\" \/><\/a><\/p>\n<h5>Validating the architecture before VS Dev \u201c15\u201d<\/h5>\n<p>To validate the architecture, you could either right-click on the diagram and chose \u201cValidate Architecture\u201d, or do the validation at build time. The former obliged you to remember to do it. The latter automatically catches architecture regressions during continuous integration.<\/p>\n<h5>This could be improved<\/h5>\n<p>To summarize a little: although this feature has existed for a while, it could definitively be improved:<\/p>\n<h6><b>Room for improvement in the authoring experience<\/b><\/h6>\n<ul>\n<li>\n<p>The authoring experience, in particular the creation of layer diagrams, was not very discoverable or usable, because the terminology was a bit obscure. In the screenshot above, few of you probably knew how to use \u201dForbidden Namespaces\u201d, or \u201cRequired Namespaces\u201d. I was certainly confused myself.<\/p>\n<\/li>\n<li>\n<p>The UX to create a layer diagram was not a simple process. You had to create a modeling project first, and then a layer diagram. And even the term \u201clayer diagram\u201d did not clearly express the intent, which is to validate dependencies.<\/p>\n<\/li>\n<\/ul>\n<h6><b>Room for improvement in the developer experience<\/b><\/h6>\n<ul>\n<li>\n<p>The validation process itself was really slow. It could take several minutes for a medium sized solution, increasing build time considerably. In theory, this could have covered multiple languages, but in practice it only worked for C# and Visual Basic.<\/p>\n<\/li>\n<li>\n<p>Validation was, therefore, not well integrated into the developer\u2019s inner loop, whereas you\u2019d really want to know when you are breaking the architectural rules as soon as you do it.<\/p>\n<\/li>\n<li>\n<p>It did not work well with the newer features of the Error list. You could not filter by error code (as you\u2019ll see in the screenshot below, there were none). You could not filter by document either, since all errors were treated as coming from the model file (the layer diagram file), and not from the offending source code file.<\/p>\n<\/li>\n<\/ul>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/05\/clip_image0023.png\"><img decoding=\"async\" width=\"793\" height=\"802\" title=\"clip_image002\" style=\"padding-top: 0px;padding-left: 0px;padding-right: 0px;border-width: 0px\" alt=\"clip_image002\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/10\/clip_image002_thumb1.png\" border=\"0\" \/><\/a><\/p>\n<ul>\n<li>Finally, when you double-clicked on a layer issue in the error list, the source code was presented in the text editor. However, because dependencies were extracted from binaries, the precise location of the validation issues was lost (there was no line number in the error list; the typical granularity was \u201cin this method\u201d. This required developer effort in order to pinpoint the issue).<\/li>\n<\/ul>\n<h4>The new \u201cDependency Validation\u201d developer experience in VS \u201cDev15\u201d.<\/h4>\n<p>Now that we share a common understanding of the gaps in the previous experience, let\u2019s have a look at what is coming in Visual Studio \u201c15\u201d. We have been rethinking architecture dependency validation, and a first step is providing live validation. We\u2019ve done this by re-implementing the validation logic as Roslyn analyzers that work against source code, provide precise information about issues, and benefit fully from the new features in the Error list and the editor.<\/p>\n<h5><b>Existing dependency validation diagrams: migration experience<\/b><\/h5>\n<p>When you open in Visual Studio Enterprise \u201cDev15\u201d a solution that you created with a previous version of Visual Studio, you will see a gold bar in the Solution Explorer, telling you that you can benefit from live architectural validation.<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/05\/clip_image0031.png\"><img decoding=\"async\" width=\"794\" height=\"603\" title=\"clip_image003\" style=\"padding-top: 0px;padding-left: 0px;padding-right: 0px;border-width: 0px\" alt=\"clip_image003\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/10\/clip_image003_thumb.png\" border=\"0\" \/><\/a><\/p>\n<p>When you press the \u201cUpdate\u201d button, projects in the solution are amended to enable live architectural validation. A NuGet package (<a href=\"https:\/\/www.nuget.org\/packages\/Microsoft.DependencyValidation.Analyzers\/\">Visual Studio Dependency Validation Analyzer<\/a>) is added, which will enable validation at build time as well (for example, during continuous integration builds). Links to the Dependency Validation diagrams in the solution are also added. In Preview 5, you see these links in the solution explorer, but we are working on hiding them for RC.<\/p>\n<h5><b>Live validation<\/b><\/h5>\n<p>After the solution is updated, assuming you have enabled full solution analysis (Options | Text Editor | C# | Advanced | Enable Full solution analysis) you will see architectural issues starting to appear in the error list. If you don\u2019t enable it, you will see the architectural issues in only the files you open, which might be what you want.<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/05\/clip_image0041.png\"><img decoding=\"async\" width=\"797\" height=\"737\" title=\"clip_image004\" style=\"padding-top: 0px;padding-left: 0px;padding-right: 0px;border-width: 0px\" alt=\"clip_image004\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/10\/clip_image004_thumb.png\" border=\"0\" \/><\/a><\/p>\n<p>As with all Roslyn analyzers, these validation errors will appear immediately you introduce unwanted dependencies, and go away as you fix the code. Note that you no longer get a \u201csomewhere in this method\u201d error. Instead, erroneous code is precisely identified by squiggles in the editor, indicating what you need to change, with explanations in a tooltip.<\/p>\n<p>Because we are now using the Roslyn framework, you should find the whole experience more familiar and consistent. You automatically get a better filtering experience in the Error List, and you are also able to manage the rules using rulesets &#8211; deciding on their severity, for example &#8211; and can manage violations using the standard suppressions mechanism.<\/p>\n<h4>What about the dependency validation authoring experience?<\/h4>\n<p>We have also changed the authoring experience to make it more discoverable and more accessible, changing the terminology from \u201cLayer Diagram\u201d to \u201cDependency Diagram\u201d.<\/p>\n<p>We have also:<\/p>\n<ul>\n<li>\n<p>Added a command to directly create a Dependency Diagram\n<a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/05\/clip_image0051.png\"><img decoding=\"async\" width=\"469\" height=\"201\" title=\"clip_image005\" style=\"padding-top: 0px;padding-left: 0px;padding-right: 0px;border-width: 0px\" alt=\"clip_image005\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/10\/clip_image005_thumb.png\" border=\"0\" \/><\/a><\/p>\n<\/li>\n<li>\n<p>Renamed the properties of a Layer in a Dependency Validation diagram, and their description, so that they are more meaningful<\/p>\n<\/li>\n<\/ul>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/05\/clip_image0061.png\"><img decoding=\"async\" width=\"794\" height=\"737\" title=\"clip_image006\" style=\"padding-top: 0px;padding-left: 0px;padding-right: 0px;border-width: 0px\" alt=\"clip_image006\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2016\/10\/clip_image006_thumb.png\" border=\"0\" \/><\/a><\/p>\n<ul>\n<li>when authoring dependency diagrams, you can immediately see the impact of your changes to the analysis results for the current code in the solution each time you save the diagram. You don\u2019t have to wait any longer for the completion of the slow \u201cValidate Dependencies\u201d command.<\/li>\n<\/ul>\n<h4>Limitations and feedback<\/h4>\n<p>You can try this experience now. What we released in VS \u201c15\u201d Preview 5 is a start, and we have more work to do, but we hope this will give you an idea of where we are heading.<\/p>\n<p>Some particular issues to be aware of in Preview 5 that will be fixed before the final release are:<\/p>\n<ul>\n<li>There is no progress feedback whilst projects are updated after pressing the Update button.<\/li>\n<li>VB support is limited to namespace\/naming rules only.<\/li>\n<li>The \u201cArchitecture\/New Dependency Diagram\u201d top-level menu command shows an empty New Project dialog. Please use \u201cFile\/New Project\u201d to add a \u201cDependency Validation\u201d project instead<\/li>\n<\/ul>\n<p>As usual we\u2019d love to hear your feedback. Don\u2019t hesitate to send feedback directly from Visual Studio (Help | Send Feedback) to report a problem or provide a suggestion.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the past year, you told us that you considered removing unwanted dependencies to be an important part of managing your technical debt. The Layer designer enables you to validate architectural dependencies in your Visual Studio solutions. It first shipped in Visual Studio 2010, and is now part of Visual Studio Enterprise. But the experience [&hellip;]<\/p>\n","protected":false},"author":77,"featured_media":45953,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,249,251],"tags":[],"class_list":["post-23025","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","category-open-source","category-security"],"acf":[],"blog_post_summary":"<p>In the past year, you told us that you considered removing unwanted dependencies to be an important part of managing your technical debt. The Layer designer enables you to validate architectural dependencies in your Visual Studio solutions. It first shipped in Visual Studio 2010, and is now part of Visual Studio Enterprise. But the experience [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/23025","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/users\/77"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/comments?post=23025"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/23025\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media\/45953"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media?parent=23025"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/categories?post=23025"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/tags?post=23025"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}