Project Gets Lost Somewhere

I don't have a good explanation for this, or a good name, but it is something that I have seen occasionally. I really need to pay a bit more attention to it, but figured I'd ask here to see if anybody recognized it, and had a solution:

I have two different development computers, and this may happen when a project is moved from one to another, but it doesn't ALWAYS happen, and I'm not entirely sure when it does happen. What happens though is that ALL the libraries appear to go missing. The references are still there, but I just opened a modestly sized project to look for a bug, and was greeted with nearly 5000 errors. These were things like System.GUID is not defined, plus a whole lot of a different type which I will mention shortly.

When I click on one of those errors, the page opens with errors all over the place, then they all go away and the error count drops by hundreds. Just the act of opening the code pages fixes all the errors on the pages, normally. It's not just code pages, either, but some of the project pages that you don't normally look at, like AssemblyInfo.vb. Every file in the project has issues, and it is issues with simple things like basic types. Opening the file is enough.

That has left me with a series of errors that don't simply go away. Clicking on one takes me to a .designer.vb file (there are still a few hundred, so it may be every control in the project) and to the declaration of a control. There's no error showing on the line, and the line is fine. The error message is annoyingly difficult to get my hands on, so I'm going to try retyping one of them:

Quote:

---

requested operation is not available because the runtime library function 'System.Runtime.CompilerServices.AccessedThroughPropertyAttribute.ctor' is not defined.

---

And this is the line I am taken to, which is clearly pretty innocent:

Code:

---

Friend WithEvents lbTotalRelSites As System.Windows.Forms.ListBox

---

These are not going away, and since there are about 400 of them, so they obscure everything else. I expect that they are some kind of problem related to the project file, or something like that, but I'm not sure.

I also have a whole bunch of simple types being undefined, as I mentioned earlier, but these are all in the file vbc. If I click on that, nothing happens. I don't have such a file in the project, so this must be something that the project is keeping track of. There are some other errors with a file called VBC (as opposed to the lower case vbc mentioned earlier).

I've seen this before, and just visiting all the errors caused them to vanish. This is the first time that I've had errors that didn't vanish.

Does anybody have any suggestions as to what is happening here?

Gitea + MS Build Tools on separate clean machine + proper workflow :-)

I've found some broken references when started adding projects to independent build process (including build machines). Actually the whole build is done via some build scripts that pull latest changes from source control (Gitea in my case), restore nuget packages, compile (msbuild for .NET Framework, dotnet build for .NET Core/5+).

Some of the "mistakes" were creating test project somewhere outside the repo and then blindly (but mostly stupidly) copy some files to the main (under source control) solution, including reference to DLLs outside the repo. It compiles, it works, but... only on "my machine".

Other times due to re-organizing the projects (we are using mono-repo with many hundreds of projects) the reference to some libraries are not to the source library but to the compiled DLL which still resides in the \Bin\Debug directory. This also happens with NuGet packages when projects are moved around.

After starting to compile manually on "build machine" all these mistakes became visible. Most of the times it requires manual changes inside vbproj/csproj to the proper path of the real source library or NuGet package (e.g. ..\..\..\..\something.dll to ..\..\..\..\..\..\something.dll - you may notice DLL moved two levels up in the repo structure).

Another problem is again adding reference to some DLL which is copied to output directory and then it is missing when cloning the repository to another location. This happens when "testing" some open source projects in "Tests" dir and then referencing the project instead of adding the library source to "third party libraries" or something similar. This usually happens when the library is not on NuGet and requires manual compilation locally. Or these could be TLBs or some interop files from product you need to install locally to develop and test the app but the build machine is missing that product and without these interop DLLs the build is impossible. Proper design of repo structure is important so all projects that use third party libs that should be included in the repo in binary form are used with proper directory reference instead of something like C:\Program Files\Common\Some Big App Name\Libs\DoSomething.Interop.dll.

BTW sometimes the order of compilation is important and VS cannot determine it quickly in big projects as it is analyzing it in the background. Using separate build scripts before starting to work (get latest version, restore packages, build all, etc.) helps to reduce some of these auto-fixed errors in the errors list in VS.

It takes time, it is not "big" fun, but if you create your workflow, scripts and start using source control system, these problems will go away in the future and you will have much more happy development life(cycle).

I didn't understand the first line until I started reading the rest.

One thing to note about this 'project' is that it is essentially a plugin system with dynamically loaded pieces that could be written by anybody anywhere. For that reason, I have avoided really streamlining the build process because that isn't the real world for this project, and can hide problems. In short, this system, if it works, simply won't have a single source, single process, single repo, or anything else like that, so making my life easier by creating a system that won't be the case in the real world seems likely to cause trouble down the road.

In fact, moving the project onto this other system has revealed bugs that were due to things working because they had been on the same system using the same database. This morning I found what amounted to a minor race condition between two plugins. This has existed for years, but never mattered because the plugins were checking for the existence of a resource, and creating it as necessary. Since the resource has been there for more years than the plugins, the race condition never manifested. Only when moving to a new machine did it show up, whereupon it was easy to correct.

However, I'm not sure that any of that applies. I'm a bit of an unusual case in that my mobile development environment is because I want to be able to work on projects when I'm tens of miles from the nearest cell service, let alone internet (that may not be an issue in a few years, though). I have some constraints on how I work on this particular project that I do need to reevaluate as technology changes.

Still, it doesn't seem to apply. The project in question is a trivial thing without any dependencies on much of anything. It's just one of the plugins for the larger project. The whole project is pretty self contained, and should be readily copyable from one system to another. I have a few dozen of them, by now, and most all of them copy around just fine.

Git as source control system (and natively supported in VS for 7+ years) uses .gitignore file where are described all compiler generated dirs and files which should not be included in the repository. When you push your changes to centralized Git server (GitHub, GitLab, Gitea and others) all these ignored files are.. ignored. So cloning the repo somewhere else will immediately show what you are missing or you wrongly reference in /Bin/Debug directories for example.

Copy/paste project dirs works but you copy all the problems with that. Adding source control management to your workflow steps will help you avoid these missing references or in general avoid bad repositories. Not my explanation should sound much simpler than in previous post :-)

I had been avoiding GitHub for this particular project because it was a hobby project that I didn't want to put in a public repo, and yet didn't want to pay a GitHub license for. GitLab would make a much better solution, as they have a different structure that would suit me better. My only reason for not doing that, yet, has been inertia. After all, I do 90% of the work on one computer, and only move things once or twice a year. Therefore, my backup has been to OneDrive.

Still, that doesn't get at the main question. Sure, a different strategy would....be a different strategy, but it doesn't get at why this project appears to have lost track of the most basic of includes in .NET. After all, it has lost track of the fundamental data types, as if System were not included.

So move to your second machine, extract the source in separate dir and try from command prompt to msbuild your solution. You may need to add to environment path to msbuild or use some of the VS dev command prompts.

Build the solution, see first project with errors, go to directory and msbuild there to find specific problems. Fix the project file dependencies or wrong dirs using text editor until you get correct compilation. If project depends on another project you have to find the leaves and move slowly to the root (your solution).

Note that msbuild needs asp arameter sln or vbproj name only if there are more of the same in the directory. If not - it will use the unique sln or vbproj so you don't have to type it manually and just run "msbuild".

That was an interesting suggestion, but I'm not sure what to make of the output. All I get is the same thousands of errors. The ones that got 'fixed' by opening a file simply came back, as they are doing in VS. The basic types, such as Date, GUID, and so forth, are not recognized.

However, I did solve the problem, though perhaps by mistake. The project was referencing a dll that I knew I had to dispense with. I haven't quite decided how I want to dispense with it, but I knew I had to dispense with it, because plugins can't work that way. When I removed the reference, all the problems went away.

Therefore, I feel that in this case, the ultimate issue was that the reference to a dll that wasn't available was causing the inclusion of references to fail right away. If the references in the vbproj file are iterated through in a linear fashion, and in order, then perhaps processing include files stops when the first one fails. That doesn't seem reasonable, as those appear in the vbproj file in what looks like alphabetic order, in which case the utterly essential 'System' reference will come very late in the order in almost any project. Still, it fits the behavior, since the fundamental types are defined in System, so if processing of all includes failed as soon as the first failure was reached (in this case, the dll that wasn't available began with an f), then even the types defined in System would fail.

The problem with such an approach is that the underlying issue becomes utterly obscured by the thousands of unrelated problems that arise when System isn't included. In this case, the key was that I couldn't find the vbc file. When I looked through the vbproj file, I STILL couldn't find the vbc file, though I could find every other meaningful file from the project. That got me to realize that the one piece that I didn't know about was that missing dll, so I just decided to remove the reference and see what happened. What happened was that all the misdirection errors went away, along with every other error.

Could it really be that the includes in the vbproj file are just alphabetic, and that they are simply processed in order with all processing stopping at the first failure? It seems much more reasonable to have each one processed regardless of the success or failure of any of the others. By doing that, it seems like the essential and boilerplate references, such as System, would all get processed even if one reference was missing, and that would result in an error set that was a whole lot more focused than thousands of errors that were only due to processing having been halted where it was.

I assume you do a Rebuild rather than a Build when you move the project from one computer to another.

The likely reason for the issues is not the order of references etc, but the fact that the contents of one of them is unknown.

As a library is missing, the compiler cannot tell if it contains a class/method/etc with the same name (which may have been the one you intended), so rather than use what might be the wrong one, it gives the error at that point... or in this case, a large amount of errors on things that aren't using fully qualified names.

That's an interesting idea, but I'm not sure it quite fits. After all, the error messages were fully qualified. I certainly don't write 'System.Boolean' whenever I declare a Boolean value, but the error message said that 'System.Boolean' was not defined, which suggests that System itself, was missing. It acted like it knew enough to fully qualify, since it showed System.Boolean rather than just Boolean.

@Passel: Heck, I sometimes do a rebuild rather than a build anyways, because they are close together and I pick almost at random for a tiny project.