Element with id is already registered. (possibily conflict with .csproj file)

[Abhinav1217]

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

• Create new project using dotnet new razor -o crud and cd into it.
• By default it creates .csproj file only, so create a solution file using dotnet new sln and dotnet sln add .
• open the project in vscode-solution-explorer

Expected behavior I should be able to see all the files and folders in the project. But error throws up.

Screenshots

Environment (please complete the following information):

• OS: Windows 11 / Ubuntu 22.10
• Version vscode-solution-explorer v0.8.1
• vscode version 1.76.2(user setup)

Additional context

Support for projects using just .csproj should also be included since dotnet command line tool does not generate sln file by default. Visual studio can work with .csproj file without generating sln file, I hope this extension can also work in similar manner because vs is not crossplatform, only vscode is,

[fernandoescolar]

Hi @Abhinav1217,

I am currently working with a mac (with apple silicon) and I don't have access to an x64 machine. On my computer I cannot reproduce your issue.

• OS: macos 13.2.1
• vscode-solution-explorer: v0.8.1
• vscode: 1.76.2
• dotnet cli: 7.0.200

I have followed your steps, in the terminal:

dotnet new razor -o crud
cd crud
dotnet new sln
dotnet sln add .
code .

And what I see is this:

no errors... Could you please provide us with more information?

On the other hand, about opening .csproj files without .sln, the last time I used Visual Studio Enterprise, when you opened a project without a solution file, it created one on the fly. Maybe vscode-solution-explorer could reproduce this behavior as well...

[Abhinav1217]

At present, there is option to create sln file but it is not needed by Visual Studio Community edition. The current project I am working on, has a multi project setup, and does not have sln file, I had to create the file for my usage in vscode.

About the reproduction of issue. It happens while I am frequently using it. Once it starts showing issue, I can close vscode, and restart it, then indexer runs again and issue is gone, until it is back in after few minutes of usage. By usage, I am talking about actively interacting with the solution explorer, like exploring files, building and watch running, using mouse and context menu. If I hide the sidebar and use the vs-code specific functions like ctrl-P to work on file, and commands on terminal, that doesn't cause issue, but then it kind of defeates the purpose of me installing the extension.

[xujun032]

I also have this issue,i don't know how to reproduced

[szoliver]

I also have this issue,i don't know how to reproduced too. And, Opening directory tree too slow, It will take a long time, a long time . This issue has been present since version 0.7.

Environment (please complete the following information):

OS: Ubuntu 20.04
Version vscode-solution-explorer v0.8.2
vscode version 1.77.1
dotnet cli: 3.1.400/6.0.407

Been troubled for a long time ！！！

[szoliver]

I also have this issue,i don't know how to reproduced

嗨，兄弟，你有没有脱离IDE直接在项目目录建立文件？有没有可能跟这个有关？是不是这个插件检索项目文件时注册的文件与实际的文件冲突了，我找不到这个插件在哪里维护这些文件的目录列表。

It may be related to directly creating files or subdirectories in the project directory.

[szoliver]

    ************  Response (52.8033ms) ************ 

{ "Request_seq": 26, "Command": "/close", "Running": true, "Success": false, "Message": "\"System.ArgumentException: 'Not Open“”。\n at Microsoft.CodeAnalysis.Workspace.CheckDocumentIsOpen(DocumentId documentId)\n at Microsoft.CodeAnalysis.Workspace.<>c.b__199_0(Solution oldSolution, ValueTuple4 data)\\n at Microsoft.CodeAnalysis.Workspace.SetCurrentSolution[TData](Func3 transformation, TData data, Action3 onBeforeUpdate, Action3 onAfterUpdate)\n at Microsoft.CodeAnalysis.Workspace.OnDocumentClosed(DocumentId documentId, TextLoader reloader, Boolean updateActiveContext)\n at OmniSharp.OmniSharpWorkspace.CloseDocument(DocumentId documentId) in /home/vsts/work/1/s/src/OmniSharp.Roslyn/OmniSharpWorkspace.cs:line 106\n at OmniSharp.Roslyn.CSharp.Services.Files.FileCloseService.Handle(FileCloseRequest request) in /home/vsts/work/1/s/src/OmniSharp.Roslyn.CSharp/Services/Files/FileCloseService.cs:line 25\n at OmniSharp.Endpoint.Exports.RequestHandlerExportHandler2.Handle(TRequest request) in /home/vsts/work/1/s/src/OmniSharp.Host/Endpoint/Exports/RequestHandlerExportHandler.cs:line 29\\n at OmniSharp.Endpoint.EndpointHandler2.AggregateResponsesFromLanguageHandlers(ExportHandler2[] handlers, TRequest request) in /home/vsts/work/1/s/src/OmniSharp.Host/Endpoint/EndpointHandler.cs:line 165\\n at OmniSharp.Endpoint.EndpointHandler2.HandleRequestForLanguage(String language, TRequest request, RequestPacket packet) in /home/vsts/work/1/s/src/OmniSharp.Host/Endpoint/EndpointHandler.cs:line 226\n at OmniSharp.Endpoint.EndpointHandler`2.Process(RequestPacket packet, LanguageModel model, JToken requestObject) in /home/vsts/work/1/s/src/OmniSharp.Host/Endpoint/EndpointHandler.cs:line 130\n at OmniSharp.Stdio.Host.HandleRequest(String json, ILogger logger) in /home/vsts/work/1/s/src/OmniSharp.Stdio/Host.cs:line 218\"", "Body": null, "Seq": 1827, "Type": "response" }

[szoliver]

Fix project expansion #240 #239

[RivenSkaye]

This issue persists on Windows, can't test Linux atm, probably because the fix in 240 was replacing backslashes with the path seperator. Which on Windows is still a backslash. I think trimming trailing pathseps afterwards would fix it, as removing the trailing backslashes in my csproj made this issue vanish.

Update from 2 minutes later: Since Windows happily accepts both forward and backward slashes, I figured I'd try appending a trailing forward slash. Reloading the solution immediately resulted in the error being back. I'll open a PR to trim them Unless something is causing the last regex to be read as two backslashes on Windows, I have no idea why it doesn't work. The code honestly seems fine

[RivenSkaye]

So after digging around a bit more, I can't reproduce with @Abhinav1217's method. I have to add an item group with an included <Folder /> element specifically.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <Fodler Include="Properties/" /> <!-- Notice the typo, no problem -->
    <Items Include="Properties/" /> <!-- No problems here either -->
    <Item Include="Properties/" /> <!-- Fine as well -->
    <Folder Include="Properties/" /> <!-- The moment you add this line and save, the explorer dies -->
    <Folder Include="Properties/**" /> <!-- And this is safe too -->
  </ItemGroup>
</Project>

This leads me to believe that calling the altering this line should fix it. Unfortunately I'm no longer at the office though, so I don't have access to a build env for it at the moment. But if anyone else does, try replacing the line with const include = replacePropertiesInPath(toOSPath(xml.attributes.Include), properties);. If that fails, try const include = replacePropertiesInPath(xml.attributes.Include, properties, true); instead.

I think either the boolean is defaulting to false for some reason, or the Record in properties is somehow being evaluated as a false-y value. If neither suggested fix works, it might be worth trying to pass in {hodor: 'bran'} instead of the properties record to see if that forces it to pass.

[SlamTheDragon]

I'm experiencing the same issue, I may have triggered it by incorrectly naming a file. My project consists of multiple .csproj files, however.. deleting redundant .csproj files did not fix the issue. Cleaning the entire VSCode's cache however solved the problem.

EDIT: I have renamed a faulty folder and it fixed the problem. I cannot remove it, however.

[samritchie]

I’ve experienced this error with 0.8.5. Was possibly related to element ordering with the .fsproj - file in the same folder were not listed consecutively