projects-and-solutions | 易学教程

Cannot add reference to project because of a circular dependency error

阅读更多关于 Cannot add reference to project because of a circular dependency error

I created 2 dummy projects in my application and named them BAL and DAL . When I build them, they build successfully. If I add a reference to BAL to the DAL project, it added nicely. But while adding the DAL reference to the BAL project, I get the following error: A reference to DAL could not be added. Adding this project as a reference would cause a circular dependency. Can anyone help me to solve this error? Prime By Design Here's what you need to do: Right click on the DAL Project in the solution explorer and select Project dependencies in the context menu. You will now see a window that

Modify programmatically csproj files

阅读更多关于 Modify programmatically csproj files

I have source code of Entlib 5.0 and I need sign all assemblies using my own key (snk file). The easiest way would be to open the EnterpriseLibrary.2010 solution file in Visual Studio 2010 and then for each project select Properties->Signing and select Sign the Assembly and then select your key file. But I don't want to manually do that then I could write a script to manually edit the project files and insert the following at the end of the current list of PropertyGroups: <PropertyGroup> <SignAssembly>true</SignAssembly> </PropertyGroup> <PropertyGroup> <AssemblyOriginatorKeyFile>keyFile.snk<

What are the project GUIDs in a Visual Studio solution file used for?

阅读更多关于 What are the project GUIDs in a Visual Studio solution file used for?

问题 I have multiple projects in a single Visual Studio (2008) solution. I just discovered that each of these projects uses a same GUID, so in the solution file it looks like this: Project("{FAE04EC0-F103-D311-BF4B-00C04FCBFE97}") = "Pro1", "Pro1\Pro1.csproj", "{...}" Project("{FAE04EC0-F103-D311-BF4B-00C04FCBFE97}") = "Pro2", "Pro2\Pro2.csproj", "{...}" Do I have to change these GUIDs so they're unique and what are they used for? 回答1: Project persistence block in a solution file has the following

ASP.NET MVC project “not supported by this installation”

阅读更多关于 ASP.NET MVC project “not supported by this installation”

I can create new MVC projects and they work and run however trying to open an existing project is not working at all I tried the following changing the project type to: <ProjectTypeGuids>{F85E285D-A4E0-4152-9332-AB1D724D3325};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids> (this worked on migrating a project from Asp.Net MVC preview 1 to preview 2 BTW) Changed the Reference to: <Reference Include="System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <SpecificVersion>False<

When do you decide to split up large projects into smaller projects?

阅读更多关于 When do you decide to split up large projects into smaller projects?

问题 When/where do you decide to split a large Visual Studio project into smaller multiple projects? If it can be reusable? when project is too big? (but how big is too big?) and When you do split the project, do you, group by database tables group by similar functionality other.. 回答1: Pros of many projects: Easier to isolate code for unit testing. I like to isolate code that has a dependency on a big external server thing, for example code that talks to the SMTP server gets its own assembly, code

NuGet and multiple solutions

阅读更多关于 NuGet and multiple solutions

问题 We have two solutions: foo.sln and bar.sln I have a common library that is used by both foo and bar. Common.csproj is used by both. If I open foo and update nuget references, all references in Common.csproj point to foo/packages/. If I later open bar and update nuget references, all references get set to those in bar/packages/. Naturally, this pisses off the foo team as it can cause incompatibilities between Common.csproj and Foo-specific stuff like Foo.Data.csproj, which still points to foo

Should a .sln be committed to source control?

阅读更多关于 Should a .sln be committed to source control?

问题 Is it a best practice to commit a .sln file to source control? When is it appropriate or inappropriate to do so? Update There were several good points made in the answers. Thanks for the responses! 回答1: I think it's clear from the other answers that solution files are useful and should be committed, even if they're not used for official builds. They're handy to have for anyone using Visual Studio features like Go To Definition/Declaration. By default, they don't contain absolute paths or any

Visual Studio Project vs. Solution

阅读更多关于 Visual Studio Project vs. Solution

Being new to VS, how may I think of these two concepts, what is the difference? A solution is a container for projects, and tracks dependencies between projects. I find some missing information in the other answers (at least for people who come from other IDEs like, say, Eclipse) . To say that a solution is a container for projects is only part of the thing. The conceptual feature of a VS project (what determines its 'granularity') is that one project produces one output : typically an executable or a library (dll). So, if you are going to code three executables that uses related code, you'll

Is there any guidance on converting existing .NET class libraries to portable libraries?

阅读更多关于 Is there any guidance on converting existing .NET class libraries to portable libraries?

I have some class libraries with a non-trivial amount of existing code. The class libraries currently target .NET 4.0. Is there any guidance on how to convert these libraries to be portable libraries? From looking at the .csproj, it doesn't appear that there are a lot of differences: <Import Project="$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets" /> and <ProjectTypeGuids>{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids> Is it a good or bad idea to try converting an existing class library

What is “src” directory created by Eclipse?

阅读更多关于 What is “src” directory created by Eclipse?

I just installed Eclipse. The Eclipse created the "workspace" folder. In this folder I created a "game" sub-folder (for my class called "game"). I have already .java files for that project (I wrote them in a text editor before I started to use Eclipse). I put all my .java file into the "game" directory. In Eclipse I created a "New Java Project" from existing code. What wanders me is that the Eclipse create a "src" sub-folder into my "game" folder. As far as I understand "src" stands for "source". But my source (.java files) is in the "game" (by the construction). Am I doing something wrong?