Csla.Analyzers.dll is not present in release 5.5.4

[kmreid]

After updating my project to CSLA 5.5.4, I'm getting a build error:

Metadata file '..\packages\Csla.5.5.4\analyzers\c#\Csla.Analyzers.dll' could not be found

This is an issue with 5.5.4 - pulling 5.5.3 from nuget includes the analyzers dll, while 5.5.4 does not. (This may also be an issue in other releases of old versions that were created last year to fix security vulnerability warnings.)

5.5.4 Pull Request for reference: #4141

Version and Platform
CSLA version: 5.5.4
OS: Windows
Platform: ASP.NET, ASP.NET Core

Stack Trace or Exception Detail
Metadata file '..\packages\Csla.5.5.4\analyzers\c#\Csla.Analyzers.dll' could not be found

[rockfordlhotka]

I've run into this in the past, and it is usually a caching issue with Visual Studio or in the obj folders in your solution.

[kmreid]

Same issue occurs with a fresh clone of my repo into a new folder. I've also tried running nuget install directly, with the same result. It's pretty easy to replicate the issue - just copy nuget.exe into a folder and then run the install:

.\nuget.exe install CSLA -Version 5.5.4 -Source $source https://api.nuget.org/v3/index.json -Framework NETSTANDARD20 -OutputDirectory "packages"

When this is run for 5.5.3, Csla.Analyzers.dll is present, but it's missing with 5.5.4.

[rockfordlhotka]

Unfortunately I don't have any machines that can still build v5, and so I rely on other folks to do the build and provide me with the resulting /bin folder output. I'm guessing it is either a build or packaging issue.

UPDATE: looking at the release.zip file from the PR, the analyzers are in the netstandard3.1 folder, so I'm guessing it is a packing issue where the assemblies somehow didn't make it into the nuget package.

[rockfordlhotka]

Being several versions behind current, this is normally "out of support". My question @kmreid, is do you need the specific bug fix that is in this version (compared to 5.5.3), and is it something that is stopping you from moving forward?

To fix this correctly, I will need to find someone who can still get a clean build of CSLA 5 so they can build a 5.5.5 and provide me the output of the build. That may or may not be possible anymore, as the targets for v5 (in terms of .NET, Xamarin, etc.) are way out of date and out of support now as well.

[kmreid]

@rockfordlhotka I'm not blocked, I just want to remove the security vulnerability warning that was fixed in 5.5.4. I guess I could update to a newer version of CSLA, but I tried that a few months ago and was unable to make it work with my application (can't recall the exact reason).

I can try building CSLA 5 if you can give me some instructions to follow, including how to build the analyzers and how to check they were packaged correctly.

[hurcane]

If you just want to get a usable binary, you could fork the repo, clone it to your local machine, check out the v5.x branch, and build it locally. Instead of using NuGet to get that version of Csla, make the DLL you compiled available internally and change your projects to use the internal copy.

Going from 5 to 6 can be a lot of work, but the benefits are well worth it. We updated last year from 5 to 8, and it took one developer about 6 weeks to apply the updates to approximately 500 business classes. 5 to 6 was the biggest change, but it was mostly the same work repeated across files. If I had an AI co-pilot, I think that could have taken less than 6 weeks.

6 to 7 was relatively painless.

7 to 8 was a challenge because there are numerous breaking changes to the configuration classes, and I could not find a nice summary that described those breaking changes. We haven't upgraded to 9 yet.

[rockfordlhotka]

I have narrowed this down to a problem with creating the nuget package itself. The zip file does contain the analyzer assembly - somehow it didn't get copied into the nuget package.

Now the problem I have is that I can't update nuget.org without increasing the version number of the package. The way we were creating the packages back then is tied directly to the assembly version of Csla.dll, but I might be able to override that in the powershell script in the /csla/nuget folder. It is either the "build all" script, or the "build" script - I don't recall which one gets the version from Csla.dll - and I think we just need to replace that check with a hardcoded 5.5.5 version (or maybe 5.5.4.1?).

@kmreid if you want to try to get this sorted out, do this:

1. Pull down the csla repo from github
2. Switch to the v5.x branch
3. Download the release.zip file from the 5.5.4 PR
4. Unpack the release.zip file _into the /csla/bin directory structure (delete that structure first, so it is clean)
5. You should (iirc) then have /csla/bin/release with stuff in the release directory
6. Open a powershell window, navigate to the /csla/nuget directory
7. Edit either "build all" or "build" to hard-code the 5.5.4.1 version for all packages
8. Run the "build all" script to generate the nuget packages
9. Rename the Csla.nupkg file to have a .zip extension, open it, and confirm that the analayzers directory has the dll

I am teaching a Blazor class Mon-Thur, and probably won't have any time to try this until Friday or later.

[kmreid]

I'll try that tonight

[kmreid]

I think that worked. I ran "build all" and it all completed, apart from one error for UWP:

"Error NU5005: Failed to build package. Ensure 'E:\Dev\csla\NuGet\deftmp\UWP.NuSpec' includes source and symbol files. For help on building symbols package, visit https://docs.nuget.org/."

I'll check on that in a moment, but apart from that, it looks fine, and I now have a folder with a bunch of Csla.xxx.5.5.4.1.nupkg and snupkg files. I can confirm that Csla.5.5.4.1.nupkg contains Csla.Analyzers.dll under /analyzers/c#/.

Note: the dlls within the nupkgs are all at 5.5.4.0, so I assume a code update and rebuild will be needed before I can submit a fix, or the dll versions won't match the package version - or is that ok?

[rockfordlhotka]

I don't know if it is ok for the nuget and assembly versions to vary. I think we should increment the assemblies to 5.5.5 to be safe.

In the v5.x branch there is a doc with an example grep command to update all the versions in the codebase.

https://github.com/MarimerLLC/csla/blob/v5.x/docs/dev/Create-a-CSLA-.NET-release.md

These days the version is in one place, but back then it was in each individual project 😢

Once the versions are updated, a PR to the v5.x branch will be necessary to keep github up to date.

iirc, the uwp package never did build with symbols - it was some limitation of uwp I think. As long as it includes the actual dll, that's what matters.