Visual Studio Team Services (VSTS) online https://www.visualstudio.com is a wonderful tool: I don’t have to build and maintain my own TFS server; the cost is nearly free; and the CI / CD (Continuous Integration and Continuous Deliver) is turning out to be a time saver…. in the long run. However I found the learning curve to be a couple of days steep, and that was painful in the middle of a project when I’m the only developer on staff, and the interface is changing as I write.

What brought me here was that my Visual Studio Solution was getting large, 17 projects, and slow. Testing, and other unknown causes was causing the Visual Studio Application to restart, destroying test results and eating time.

I started preparing Solutions containing each component of the application and its tests. My immediate goal is to upload Enterprise Employee data from Viewpoint to Namely.com, and eventually some data may become bi-directional. I’ve found that splitting out the interfaces into their own Project keeps me somewhat more honest about coding to the Interface, and tends to make my .NET Core Project using Dependency Injection a bit clearer to my own thinking.

I uploaded the lowest level Solution, “WEI.Common.Interfaces” to VSTS and started to construct a Build Definition. What I really wanted to find, and didn’t, was a simple example of what success might look like for a real production ready Solution and Build; dare I say “I’m hoping to display that for you now.”

Caveats

In the .NET Core .csproj file, even if you turn off Signing, and set it as packable, some of these will come back to haunt you. Edit the .csproj file and verify these values are set, and that there is no AssemblyOriginatorKeyFile tag listed.

Build and Release

.NET SDK 2.1.301

In order to build at other than 2.0.0, you need to specify which SDK you want used.

<include date=”2018-11-13″>

With the advent of .NET Core Runtime 2.1.6 I had to add a second .NET Core Tool Installer: The first being Use .NET Core Runtime 2.1.6 and the second being Use .NET Core SDK 2.1.500 (contains runtime). Note that they don’t work in the reverse order, and SDK 2.1.5 doesn’t cut it…. you need to specify 2.1.500 exactly. With these additions you may also make use of these as appropriate

1. Feed

You will want a Feed set up in “Build and release”, “Packages”, “+ New Feed” , and along the way you will want to add that to your Visual Studio NuGet Package Sources.

2. Releases

You will want to set up a release. I’ve not worked out all the bugs yet, but you have to release the package or it will continue to show as a Pre-Release package.

3. Release Pipeline

Using the pipeline you can release multiple Solutions / Builds as a set.

4. Build And Release

5. Build Definition

A couple of these steps are disabled, and you may notice that the .NET Core Tool Installer is missing, as I discovered it later.

6. Phase 1

7. Restore

8. Build

9. Test

10. Pack for Publish

I’ve found that I prefer the “Pack Options” of “Use the build number”, though you need to set the Build Definition Options “Build number format” as ‘$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) (2018-07-10 ewm)

10a. Build Definition Options

Set the Build Definition Options “Build number format” as ‘$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) (2018-07-10 ewm)

11. Publish to Feed

12. Publish Symbols Path

13. Publish Test Results

This task is only of value if you use NUnit or other third party test extensions. If you are using [Microsoft.VisualStudio.TestTools.UnitTesting] this is unnecessary. (2018-07-10 ewm)

14. Publish code coverage

This step is only needed if you are using one of the Code Coverage Tools selectable. (2018-07-10 ewm)

15. Copy Files

16. Publish Artifact drop

17. Promote package to Release View

Not having any luck getting this task to execute successfully and auto-release new builds into the package feed. (2018-07-10 ewm)

System.IO.FileNotFoundException HResult=0x80070002 Message=Could not load file or assembly 'System.Runtime, Version=4.1.1.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of
its dependencies. The system cannot find the file specified. Source=<Cannot evaluate the exception source> StackTrace:<Cannot evaluate the exception stack trace>Inner Exception 1:FileNotFoundException: Could not load file or assembly 'System.Runtime,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of
its dependencies. The system cannot find the file specified.

This particular problem is one of those I’ve run into before, and is an immediate introduction to “dll hell”. I have just this morning, mindlessly (“Just because you can”), applied the latest update of RestSharp v106.2.1 and libphonenumber-csharp 8.8.9 to my Visual Studio Solution. This has the repeated and unfortunate consequence of adding to the web.config:

Resolution of this exception is easily handled by removing the offending lines from the web.config file.

The root cause of this problem was best explained by an article I’ve lost track of at the moment, if I find it again I’ll link it here and give the appropriate credit…. essentially the transition from project level references to NuGet package references is not complete, and thus introducing these types of errors. It was expected that as ASP.Net Core matures, and the changes are fully migrated into the Visual Studio environment that this type of issue will be resolved.

I’m admittedly starting in the middle, as I write this article; the Walker Engineering, Inc API (WEIAPI) is intended to be the architectural foundation for a full Service Oriented Architecture leveraging Azure and a Hybrid SQL Data Model which I’ll discuss in more detail in another article.

This utilizes a traditional layered architecture modified in part by Jeffrey Palermo’s Onion Architecture concepts, here is a view of the current Visual Studio 2017 dependency validation layer diagram to give you an idea of the overall architecture:

I’ll not claim that this is bleeding-edge architecture nor the most ideal solution; that’s what I had hoped to build, but as I review problems originating in this Solution I fear that I may targeted an architecture somewhere between 10 and 5 years old. Though my idea of the latest solution may ultimately change again over time, I’m beginning to think I should have founded the solution on ASP.NET Core with Microsoft.OData.Core, though I’m uncertain this model is yet mature enough to meet our needs.

In any case I’ve built an “ASP.NET Web Application (.NET Framework)” project enabled for Azure, MVC and Web API then updated by numerous NuGet packages including Microsoft.AspNet.WebApi, Microsoft.AspNet.Mvc and relying on Entity Framework 6.2. Some important considerations in choosing this architecture however are that

The solution should make use of industry best practices, thus the traditional layered architecture.

The solution should reside in the Azure Cloud and make us of the latest cloud technologies.

As Walker Engineering currently utilizes Vista by Viewpoint as our primary Enterprise Resource Planning (ERP), and Walker has no direct control of the version, schema, or even update interval which is largely driven by operations departments, and best practices, the assembly for the Viewpoint database is a Entity Framework Model First with minimal modifications to minimize the impact of database changes.

The construction of program models, especially at domain boundaries is one of the most time consuming aspects of programming, so AutoMapper and AutoMapper.EF6 were used to speed this process; though unfortunately AutoMapper has recently transition from a static to an instanced architecture resulting a plethora of essentially unusable codes samples across the Internet, and some hopefully only temporary loss of functionality.

In order to maintain the layer separation, Inversion of Control (IOC) design was required, most notably in the Data Access Layer making use of Ninject to prevent a direct dependency from the Business Logic Layer to the Data Access Layer.

The Business Logic layer utilizes the Repository Pattern sans Unit of Work as the REST API architecture essentially duplicates it, and the Entity Framework is directly executing it.

JetBrains ReSharper product has been invaluable for keeping the code clean, and implementing various refactoring along the way.

Unit Testing has been critical for ensuring that the refactoring hasn’t broken the entire solution permanently.

Visual Studio Online has been critical for preventing a total loss when things have gone sideways, as has occurred several times.

Though I’ve received great value from the Visual Studio “NuGet Package Manager”, I’ve also become familiar with the term “dll Hell”; which I’ve seen discussed on many web sites, and which has in great part prompted my decision to blog again. I feel the need to begin detailing the errors I’m receiving as I build these assemblies. It appears I keep running into the same problems over and over again, and so far I’ve been relying on memory to resolve the issues; yet I observe as I research the problems on the Internet that many others are running into the same sort of problems.

Related articles will be tagged with “WEIAPI”, a Layer Name from the image above, and an Assembly Name where applicable.

1,232 days to be exact; I told you I don’t talk much… My current code project is actually what is motivating me to begin writing again. I think it an elegant design, but implementation is literally giving me headaches, probably due to excess blood loss being so near the bleeding edge; though there are Internet articles that lead me to believe I may still be years behind the current technology, I’m trying to catch up.

Much has happened since 2014/08/27, I’ll try not to wax loquacious. In reverse order, and not necessarily precise, or even accurate I think:

2017-10-07 My father James Kern McCarty passed away of a massive stroke after almost 3 days and then comfort care. He was hospitalized from his 74th birthday 2017-09-17 until his passing, though most days he was generally lucid, he wasn’t happy about being in the hospital, and his memory was faulty due to micro-strokes.

2014-04-23 My Aunt Jo was Married again at 72 years old

2017-04-12 My daughter Jessica Espinoza visited with her children Cadence and Adell.

2017-03-27 We traded in the Silver Toyota Lease Purchase for a red Toyota RAV. I’m still convinced that with little or no down payment a lease on a base model is better than a purchase. The trick is to avoid all the upgrades during the buying process.

2017-03-14 (Pi day) I began work at Walker Engineering, Inc at their corporate office in Irving, Texas.

2016-12-16 Chris Zeppa, the same CIO who hired me at Parker College 12 years ago, has opened negotiations for a position at Walker Engineering, Inc; rejoining my old team Judith Hotek, and Jeff Kadlubar.

We have an issue with the several computers that have 4.5.7 installed. We’ll get the computers setup with new users and log into Product with full functionality. Sometimes a day or a week later the same user will attempt to log into Product and will receive this error.

Our fix has been to reinstall the app starting with Version 4_5_2 and finishing with the latest Version_4_5_7_2 . We were wondering if there is a known issue with a Windows Update that is causing the application to overlook the upgrades?

I’ld be willing to be that the method used to install 4.5.2 isn’t doing the installation via SCCM as originally implemented several years ago. Unless someone has disabled that deployment it is still going and will probably overwrite ..

Yep, This appears to be the case. The query to determine membership to the collection for installation simply looks for Product and does not discriminate on version. Disabled this and all other Product pushes. This should resolve the issue. I had previously disabled the push for the upgrade that I deployed but did not think to look at the older deployments.

One of our Administrators set up Microsoft NPS to log locally on the C: drive. The drive was a bit too small at 50GB, so was becoming a maintenance nightmare. We chased the problem down to the c:\windows\system32\logfiles\ folder but it took a while to figure out these were the NPS logs. We reconfigured for SQL Logging, and I didn’t want to just throw away the existing log files, so I wrote the PowerShell script below to insert the logs into the table a row at a time. Granted not the fastest solution, but I’m in no hurry…