I meet a strange problem when I use visual studio 2010. I have many projects in my solutions. When I add a folder in my solution(in visual studio, not windows explorer), it automatically changes some projects in the solution, i.e, the .csproj file. Basically, it changes the name of some projects it references. For example,
<ProjectReference Include="..\..\..\Common\Common.csproj">
<Project>{EXXXXX-XXXXX-XXX-XXXX-XXXXXXXXX}</Project>
<Name>Common</Name>
</ProjectREference>
is changed to
<ProjectReference Include="..\..\..\Common\Common.csproj">
<Project>{EXXXXX-XXXXX-XXX-XXXX-XXXXXXXXX}</Project>
<Name>Common %28Common\Common%29</Name>
</ProjectREference>
That is, it adds something to the name. but it only changes one or two project name it references, not all the projects it references. BTW, I only added a folder to the root of the solution. It's totally irrelevant to other projects in the solution.
Although this is not a big problem, it doesn't affect compiling and execution of the program, it's quite annoying. Anyone knows what causes this problem?
Related
I have a large solution in which the "root" project includes feature projects by glob:
<ProjectReference Include="..\Feature\*\*.csproj" />
This works, despite not looking great in the references list, but the issue that occasionally Visual Studio will rewrite the csproj with all of the project references resolved:
<ProjectReference Include="..\Feature\A\A.csproj" />
<ProjectReference Include="..\Feature\B\B.csproj" />
It's not clear what triggers this, but I'm guessing it might have something to do with NuGet.
Is there anyway to stop VS from doing this (akin to using DisableFastUpToDateCheck for custom MSBuild scenarios)?
It's not clear what triggers this, but I'm guessing it might have something to do with NuGet.
It should be related to the items in the ItemGroup. I have the similar issue before, but the difference is that I use wildcards to contain .cs files and your are .csproj files, looks like:
<ItemGroup>
<Compile Include="**\*.cs" />
</ItemGroup>
When I delete one of .cs file in the <ItemGroup>, the wildcard gets expanded in the csproj file. For you case, if I deleted the the C.csproj project from Visual Studio (Add it before, reload the root project), then I got the same result as you.
For this issue, many other community members submit a user voice to Visual Studio team: VS IDE should support file patterns in project files. Now this is well supported in the new project system used by .NET Core and .NET Standard in Visual Studio 2017, but they haven't done the work to support it for existing project types.
Is there anyway to stop VS from doing this (akin to using DisableFastUpToDateCheck for custom MSBuild scenarios)?
To resolve this issue, you can use option Exclude="..." to exclude the project that you do not want to refer to:
<ItemGroup>
<ProjectReference Include="..\Feature\*\*.csproj" Exclude="..\Feature\C\C.csproj" />
</ItemGroup>
Or, if you want to delete one of project and keep the wildcard pattern, you only need to unload the root project, then delete the reference project, reload the root project, the wildcard pattern would be preserved.
Hope this helps.
I've done further research on this.
For testing, you can consistency reproduce the expansion by renaming any project that's included in the wildcard pattern.
Also, the easiest way to prevent the expansion is to:
Move the project reference globs into Directory.Build.props or another external file
Set DisableFastUpToDateCheck to true in your csproj
Using properties doesn't work and isn't required, likewise with using an Exclude.
I have a solution with multiple web projects. And there is common tsconfig which is used to build all typescript in solution. Build is called via webpack, so I don't want any typescript support from visual studio. More precisely, I want some support — in navigating and refactoring, but I don't want VS to build this code.
So I removed all references to typescript targets from csproj and everything works fine. But any time I add a new typescript file, VS gladly says
Your project has been configured to support TypeScript
and returns all typescript targets back to csproj.
Can I prevent VS from doing it? Of course I can live with it, but removing garbage from csproj after each adding seems uncomfortable.
UPD: found post on uservoice of VS https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/13420095-ask-to-configure-projects-for-typescript. But maybe there is solution already available. Or you can like this uservoice if you agree that it is an annoying problem :)
Found solution on uservoice (https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/13420095-ask-to-configure-projects-for-typescript).
Seems a bit ugly but it works.
Steps to fix:
Add some ts file to project and let VS add some bullshit to your csproj
ctrl-shift-s to make sure csproj is updated
Open csproj in any text editor and then:
Find import of Microsoft.TypeScript.Default.props and replace it's Condition="..." to Condition="false"
Remove line with TypeScriptToolsVersion
Find import of Microsoft.TypeScript.targets and replace it's Condition="..." to Condition="false"
Now after adding file VS will stop trying to do smth with project. And typescript will not be compiled on save and build, so you need to use gulp/webpack/grunt/whatever.
Visual Studio 2019 (16)
Add to *.csproj file
<ItemGroup>
<None Remove="**/*.ts" />
<Content Remove="**/*.ts" />
<TypeScriptCompile Include="**/*.ts" />
</ItemGroup>
Solution is described here: https://developercommunity.visualstudio.com/t/vs-modifies-csproj-file-with-typescriptcompile-ite/288648
I've created a new Xamarin.Android app and added a few assets to it. Those assets are available in multiple resolutions, so I placed them in their respective drawable-XXXfolders inside the Resources folder. Doing so resulted in the following error:
The project 'XXXX.fsproj' could not be opened because opening it
would cause a folder to be rendered multiple times in the solution
explorer. One such problematic item is 'Resource\drawable-hdpi\pencil.png'
This is being caused by F#'s poor folder structure handling. I usually don't need to use folders at all in F# projects, but in this specific case it's necessary because of the way Android deals with resources. The project loads fine in Xamarin Studio, but in Visual Studio it doesn't.
The project is quite big, what means I (and other people as well) will need to add a lot of files, so manual approaches like this one are of no use, for they're too time consuming.
I read the official docs but there's nothing there that states there's a special way to handle adding files on VS or another way to deal with this limitation. My question is: such thing exists? Can I add those files in another way so that I don't need the complex structure on VS? Will I be forced to use C# or Xamarin Studio against my will?
The references to folder files have to be listed together, they can not be interspersed with files in different location. Sort the refs and it will be fine.
EDIT, for clarity:
<ItemGroup>
<Compile Include="folder\file1.fs" />
<Compile Include="file.fs" /> <-- this can't be between the folder files, all folder files have to be listed together
<Compile Include="folder\file2.fs" />
</ItemGroup>
Sadly, the standard Visual Studio integration does not support folders in F# projects.
Your best option is to use the Visual F# PowerTools. This adds some support for folders to F# projects and so it may work good enough to do what you need. If it does not, then Visual F# PowerTools is an open-source project and it always welcomes contributions!
I don't know much about the Xamarin Android project types - but I guess that adding C# project which is just an empty DLL to store the resources would be a reasonable alternative too. (Then you should be able to reference this from F# and load all resources from there.)
I have an asp.net mvc web application, and i have a reference to SharpArch.Web (one of the Sharp Architecture assemblies)
When i rebuild the project, and run it, an exception is thrown telling me that the (Newtonsoft.Json.dll) is missing from the Bin folder which is used by (SharpArch.Web), so it's ok, i copied it, and every thing worked well.
When i try to rebuild the project again, the exception is thrown again, and the (Newtonsoft.Json.dll) assembly is deleted ??
Why did that happen? what does visual studio have to do with non-referenced assembly ?
and FYI, VS doesn't delete everything from Bin, just a specific assemblies !!!
and BTW i don't want to add a reference to (Newtonsoft.Json.dll), i don't like to reference an unused assembly.
I had the same situation on one solution I was working on. So I ended up putting those .dll's into a separate folder. In my case I named this folder "ServerAssemblies". Then I modifyed my project file (.csproj in my case) and added an "AfterRebuild" target. That way there is noe need to add references to unused assemblies to the project.
<Target Name="AfterRebuild">
<ItemGroup>
<ExtraAssemblies Include="$(SolutionDir)ServerAssemblies\**\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(ExtraAssemblies)" DestinationFolder="$(ProjectDir)bin\"></Copy>
</Target>
I suppose that the Bin\ directory is reserved for mangling by Visual Studio. You'll have to put your assembly in a different location.
I work in a team on a Visual C++ project. Following advice we got we're tracking the project's .sln file with our SCM. It turns out that each time I pull from my partner (yes, we use git) and open the solution in VS, the .sln file is updated. The part being updated is the long id that appears several times (in this case ending with 7C44) in the following segment:
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Debug|Win32.ActiveCfg = Debug|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Debug|Win32.Build.0 = Debug|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.DebugStaticCRT|Win32.ActiveCfg = DebugStaticCRT|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.DebugStaticCRT|Win32.Build.0 = DebugStaticCRT|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Release|Win32.ActiveCfg = Release|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Release|Win32.Build.0 = Release|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.ReleaseStaticCRT|Win32.ActiveCfg = ReleaseStaticCRT|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.ReleaseStaticCRT|Win32.Build.0 = ReleaseStaticCRT|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Template|Win32.ActiveCfg = Template|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Template|Win32.Build.0 = Template|Win32
What does this number mean? How can we make it stop changing between us?
I had a difficult time finding this particular post when searching for the answer, so I just wanted to add some key words and explanation to make it easier to find. Thanks to the fantastic answers by Daniel and tgb I was able to resolve this issue and my team and I no longer have conflicting solution files after opening Visual Studio 2010 (I would vote their answers up, but I just joined today and do not yet have enough reputation points to vote answers up...).
So, to ask the question in a few more ways:
Why does Visual Studio change .sln files when opening a solution? Why do .sln files have local modifications? or What causes merge conflicts in Visual Studio Solution files?
Answer: Most likely a different or missing ProjectGuid attribute in the .vcxproj Project file will cause local modifications. This could be due to upgrading projects from previous versions of Visual Studio or just from manually copying a project file and editing parts of it.
The fix is to add the line:
<ProjectGuid>{###}</ProjectGuid>
(with the appropriate ID from the solution file in place of ###) to the .vcxproj file in the 'PropertyGroup Label="Globals"' node, for example:
<PropertyGroup Label="Globals">
<ProjectGuid>{FD0675C0-EC06-E665-4001-12DEE6694605}</ProjectGuid>
<RootNamespace>MyProject</RootNamespace>
</PropertyGroup>
Otherwise Visual Studio will just assign a new random ProjectGuid to each project and update the .sln file. The 'ProjectGuid' can easily be found for a given project in the .sln file:
Project("{<Filter#>}") = "MyProjName", "src\to\Proj.vcxproj", "{<ProjectGuid>}"
That is a GUID which Visual Studio uses to refer to the individual projects. You will find the same GUID at the top of the .sln file, where the projects are defined/imported.
Visual Studio reads the GUID from the corresponding .csproj/.vbproj file. There you should find a ProjectGuid property near the top with the corresponding GUID. If you and your partner have a different GUID defined there, the .sln will also update.
I've had the same problem.
I finally noticed it came from a vcxproj file which didn't define its GUID.
I manually added this GUID in my vcxproj file :
<PropertyGroup Label="Globals">
<ProjectGuid>{D3303AD3-B7E5-48F8-919C-18202ABAEF00}</ProjectGuid>
<RootNamespace>MyProject</RootNamespace>
<ProjectName>MyProject</ProjectName>
<Keyword>MFCProj</Keyword>
</PropertyGroup>