daveoftheparty / speedy-moq

Generate boilerplate code for Moq in C#
MIT License
1 stars 0 forks source link

internal Interface definition dict is being unnecessarily overwritten #40

Closed daveoftheparty closed 3 years ago

daveoftheparty commented 3 years ago

SourceFile attribute that was initially loaded by the csproj loader in InterfaceStore is later being overwritten by the text loader (on doc open/change). Could be an easy fix in a couple of different places:

1) in LoadCsInterfaceIfNecessaryAsync-- we know the file name because we get a TextDocumentItem 2) by simply not overwriting a source file name, but that could lead to new bugs I believe.

See this log, relevant lines are 21-23 and then 29-31

1   [Trace - 9:57:29 PM] Sending request 'initialize - (0)'.
2   [Trace - 9:57:30 PM] Received response 'initialize - (0)' in 1265ms.
3   [Trace - 9:57:30 PM] Sending notification 'initialized'.
4   [Trace - 9:57:30 PM] Received request 'client/registerCapability - (1)'.
5   [Trace - 9:57:30 PM] Sending notification 'textDocument/didOpen'.
6   [Trace - 9:57:30 PM] Sending response 'client/registerCapability - (1)'. Processing request took 1ms
7   
8   [Warn  - 9:57:30 PM] OmniSharp.Extensions.LanguageServer.Server.Configuration.DidChangeConfigurationProvider: No ConfigurationItems have been defined, configuration won't surface any configuration from the client! | 
9   [Trace - 9:57:30 PM] Sending request 'textDocument/codeAction - (1)'.
10  
11  [Info  - 9:57:30 PM] MoqGenerator.Services.ProjectHandler: method GetCsProjFromCsFile is looking for a .csproj related to file e:/temp/bugrepro/HasABug.cs | 
12  
13  [Info  - 9:57:30 PM] MoqGenerator.Services.ProjectHandler: method GetCsProjFromCsFile is searching for a .csproj in e:\temp\bugrepro | 
14  
15  [Info  - 9:57:30 PM] MoqGenerator.Services.ProjectHandler: method GetCsProjFromCsFile found e:\temp\bugrepro\bugrepro.csproj | 
16  
17  [Info  - 9:57:30 PM] MoqGenerator.Services.ProjectHandler: Loading project references for project e:\temp\bugrepro\bugrepro.csproj | 
18  
19  [Info  - 9:57:33 PM] MoqGenerator.Services.InterfaceStore: LogDefinitions was called by LoadCSProjAsync. CsProjs loaded: e:\temp\bugrepro\bugrepro.csproj | 
20  
21  [Info  - 9:57:33 PM] MoqGenerator.Services.InterfaceStore: LogDefinitions was called by LoadCSProjAsync. Interfaces loaded: 
22  bugrepro.IThing : e:\temp\bugrepro\HasABug.cs
23  bugrepro.Tests.IThing : e:\temp\bugrepro\HasABug.cs | 
24  
25  [Info  - 9:57:33 PM] MoqGenerator.Services.InterfaceStore: method LoadCsInterfaceIfNecessaryAsync loaded for uri file:///e:/temp/bugrepro/HasABug.cs | 
26  
27  [Info  - 9:57:33 PM] MoqGenerator.Services.InterfaceStore: LogDefinitions was called by LoadCsInterfaceIfNecessaryAsync. CsProjs loaded: e:\temp\bugrepro\bugrepro.csproj | 
28  
29  [Info  - 9:57:33 PM] MoqGenerator.Services.InterfaceStore: LogDefinitions was called by LoadCsInterfaceIfNecessaryAsync. Interfaces loaded: 
30  bugrepro.IThing : 
31  bugrepro.Tests.IThing :  | 
32  [Trace - 9:57:33 PM] Received notification 'textDocument/publishDiagnostics'.
33  [Trace - 9:57:33 PM] Received response 'textDocument/codeAction - (1)' in 3521ms.
daveoftheparty commented 3 years ago

This turned out to be more serious than I thought, we're also losing some of the interfaces by namespace due to a blind overwrite of the dictionary