visual-studio-2010 - visual - vs code autoclose html

Visual Studio duplicando el archivo.cs de recursos

Question

Visual Studio ha comenzado a exhibir una peculiaridad bastante irritante. Cuando edito un archivo de recursos (usando la vista del diseñador o editando el XML directamente), se crea un archivo Designer.cs de recursos duplicados, lo que hace que el proyecto no pueda compilarse.

Ejemplo: Digamos que mi archivo de recursos se llama ProjectSQL.resx. Si expande ProjectSQL.resx en el Explorador de soluciones, muestra ProjectSQL.Designer.cs. Cuando hago una edición en una de las consultas definidas en ProjectSQL.resx, se guarda bien, pero crea otro archivo llamado ProjectSQL1.Designer.cs.

En ese ejemplo, ahora hay dos archivos de clase con el mismo nombre de clase, lo que provoca el error de compilación.

¿Alguien tuvo este problema antes? ¿Cómo lo arreglaste? He intentado cerrar la solución y volver a abrirla, así como reiniciar Visual Studio. Usando VS 2010 Premium en Windows 7 Ultimate para aquellos interesados.

Answer 1

Borre la entrada " Herramienta personalizada ". el archivo rpt apropiado está ubicado al hacer clic derecho en el archivo rpt -> propiedades ---> herramienta personalizada ---> borrar

Answer 2

Reemplace en el archivo .csproj el código como se muestra a continuación:

<EmbeddedResource Include="Resources/ProjectSQL.resx">
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>ProjectSQL1.Designer.cs</LastGenOutput>
</EmbeddedResource>

Con código como el siguiente: -

<EmbeddedResource Include="Resources/ProjectSQL.resx">
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>ProjectSQL.Designer.cs</LastGenOutput>
</EmbeddedResource>

Fuente: http://www.codeproject.com/Questions/227676/Resource-file-regenerating

Answer 3

En caso de que esto le suceda a alguien más y se encuentre aquí, el comentario de Hans anterior me indicó el archivo del proyecto. Tuve que cerrar la solución, encontrar la etiqueta LastGenOutput en el archivo XML del proyecto y cambiar el nombre de la salida del recurso a ProjectSQL desde ProjectSQL1.

Todavía no tengo idea de cómo sucedió esto. Pero al menos ya está arreglado.