Question Visual Studio Creating Folder with Old File Name

[justhumm]

A week or two ago, I renamed a Visual Studio solution/project:

from UDFakhC to AKHudfC

I can't find any files / code containing the old name (UDFakhC).

I have deleted the ".vs" folder a couple of times.

I tried deleting all of the files from all "bin" and "obj" folder(s).

But, still, whenever I compile the "AKHudfC" project, Visual Studio creates a "UDFakhC\UDFakhC\bin\debug" folder with a bunch of *.pdb folders for a few of the project references.

And the only file in each of the folders is "symsrv.miss.txt" which just contains the link "https://referencesource.microsoft.com/symbols".

The only thing that appears to be NOT working for the compiled "AKHudfC" excel add-in is the ExcelDNA Intellisense (tool-tips). And I'm guessing this extra folder might have something to do with it.

Can anyone point out or speculate why Visual Studio is creating the extra folder? Thanks!

 

[Skydiver]

Look in your .CSProj file.

 

[justhumm]

@Skydiver no dice.

That was one of my first guesses, but couldn't find any references to the old file name...unless I'm missing something.

 

[Skydiver]

Sorry, out of ideas.

 

[justhumm]

A week or two ago, I renamed a Visual Studio solution/project from UDFakhC to AKHudfC.

I updated and couldn't find any files / code containing the old name (UDFakhC). I had deleted the ".vs" folder a couple of times. And I tried deleting all of the files from all "bin" and "obj" folder(s).

The project working folder is saved in a OneDrive folder.

When I compile (either "Start" or "Build") the new project in Visual Studio on my personal computer, everything's "fine". And the expected files are created in "AKHudfC\bin\debug".

When I "Build" the new project in Visual Studio on my personal computer, everything's "fine". And the expected files are created in "AKHudfC\bin\debug".

When I "Start" the "AKHudfC" project for debugging with Excel and Visual Studio on my work computer, it creates a "UDFakhC\UDFakhC\bin\debug" folder with a bunch of *.pdb folders for a few of the project references. And the only file (for the most part) in each of the folders was "symsrv.miss.txt" which just contains the link "https://referencesource.microsoft.com/symbols" (or something similar).

When compiled on both my personal computer and/or work computer, the only thing that appears to be NOT working for the compiled "AKHudfC" excel add-in was the Intellisense (tool-tips).

...I got fed up with it, so I backed up the cs files and started a new project from scratch in Visual Studio. Same thing is still happening.

Any ideas why it's still Windows/Excel/VS is creating the bin folder with the old project name?

 

[Skydiver]

Time to do more detective work.

Open a Developer PowerShell or Command Prompt:

Got to the directory that has your .CSPROJ file.
Then run:

msbuild.exe -v:diag -t:"Clean;Build" .\AKHudfC.csproj

The carefully pore over the output. You'll likely find out how/why MSBuild (and Visual Studio) is computing that path name for you.

 

[justhumm]

@Skydiver I tried msbuild.exe -v:diagnostic -target:Clean;Build .\AKHudfC.csproj and I didn't see any references to the folder name that's being created.

I am totally unfamiliar with the command prompt, but figured since the folder only seems to be getting created when using the START button in Visual Studio and Excel is actually opened up for debugging, so I tried msbuild.exe -v:diagnostic -target:Clean;Build;Run .\AKHudfC.csproj

And the Run target failed, because the project creates a *.XLL file and not a *.EXE.

Is there any way to get MSBUILD to invoke the project start action (Start external program)?

Done building target "AfterBuild" in project "AKHudfC.csproj".: (TargetId:86)
Target "ExcelDnaBuild" skipped. Previously built successfully.
Target "ExcelDnaPack" skipped. Previously built successfully.
Target "Build: (TargetId:87)" in file "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets"
from project "C:\Users\~\AKHudfC\AKHudfC.csproj" (entry point):
Done building target "Build" in project "AKHudfC.csproj".: (TargetId:87)
Target "Run: (TargetId:88)" in file "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets"
from project "C:\Users\~\AKHudfC\AKHudfC.csproj" (entry point):
Using "Error" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "Error" (TaskId:60)
  Task Parameter:Text=Cannot run 'C:\Users\~\AKHudfC\bin\Debug\AKHudfC.dll' because project output type is not '.exe' (TaskId:60)
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(1110,5): error :
Cannot run 'C:\Users\~\AKHudfC\bin\Debug\AKHudfC.dll' because project output type is not '.exe' [C:\Users\~\AKHudfC\AKHudfC.csproj]
Done executing task "Error" -- FAILED. (TaskId:60)
Done building target "Run" in project "AKHudfC.csproj" -- FAILED.: (TargetId:88)
Done Building Project "C:\Users\~\AKHudfC\AKHudfC.csproj" (Clean;Build;Run target(s)) -- FAILED.

 

[justhumm]

In Visual Studio, I went to [ Tools --> Options --> Projects and Solutions --> Build And Run ] and set the MSBuild verbosities to "Diagnostic".

I hit the Start button and...

According to Windows Exporer (folder properties), the extra folder is created at 05:08:35pm. And the deepest-ish file within that folder is created at 05:08:48pm.

I copied and looked at the Output window for Debug, Build, and Build Order. There's no reference to that folder that was created.

According to the Build (and Build Order) Output log, the Build started at 17:08:31:992 and succeeded at 17:08:32:455.

According to the Debug Output log, the first reference to EXCEL.EXE (symbols loaded) is at 17:08:37:067 and exited at 17:09:27:507.

Any idea where I might try to dig up what created that folder?

 

[cjard]

How did you determine that no file contains AKHudfC? Didyou use a decent, external text editor to do a "Find In All Files", or did you use VS's own search, or worse Windows search (which only looks inside certain file types) ?

I would download Sublime text, or Nir Sofer's SearchMyFiles, invoke a Find In Files at the very root of the project folders, for your target string and see what comes up. If nothing, then I'm struggling to see how VS can still have memory of it..

 

[justhumm]

@cjard I did a text search with both VS and Notepad++. Maybe I'll give it another shot with one of your recommendations, but the code/files aren't that involved that anything "should" be hard to find.

The working folder is saved on the cloud, so I'm wondering if the file version history is messing with VS's compiler. Might try just shutting off the version history and see how it goes.

 

[Skydiver]

Tip: Never store source control directories (git, mercurial, SVN, perforce, etc.) in cloud syncing technologies like OneDrive, Google Drive, DropBox, etc. unless you are sure that the syncing technology can do "atomic" syncing with the cloud where "atomic" is defined to be all the files correspond to known versions from the point of view of the source control system. I was burned by this in the early predecessors of OneDrive (aka Mesh v1, and Mesh v2), as well as, current versions of DropBox. I ended up with corrupted Perforce, SVN, and git working directories.