I have inherited a very disorganized VSS database and I need to clean it up. Before I finalize my reorganization, I would like to get some guidance so I don't make similar mistakes as the previous person. I'm going to move everything to a new instance of VSS and start fresh. Historical information isn't a concern, so it is understood that the fresh install will not include history of prior versions. (The current VSS db will be available if needed.)
We are currently using Visual Studio 2005 and Visual Source Safe 2005. We'll be moving to VS2010 and perhaps TFS, but first steps first.
We have three ASP.NET products, each of which share multiple libraries. Here's the basic structure of the projects:
PRODUCT 1
References:
Library 1
References:
Library 4
Library 5
Library 2
Library 3
PRODUCT 2
References
Library 1
References:
Library 4
Library 5
Library 3
Library 6
PRODUCT 3
References
Library 5
Library 3
As a first step I have all of the products and libraries "Unbound" from VSS and have structured them in folders as follows. (There are 3 developers and we'll all setup the same folder structure on our machines.)
C:\Source\Products\Product1
C:\Source\Products\Product2
C:\Source\Products\Product3
C:\Source\Libraries\Library1
C:\Source\Libraries\Library2
...
C:\Source\Libraries\Library5
Each Product and Each library has it's own solution; project references are used for all referenced libraries. For example, the solution for PRODUCT 1 includes project references for Libraries 1, 2, 3, 4, and 5. The solution for Library 1 has project references for Libraries 4 and 5 and so on. Everything builds at this point.
Question: Is it common practice for PRODUCT 1 to include project references for Libraries 4 and 5 even though it doesn't reference them directly (Yet one of its referenced projects does)?
I plan to setup a parallel structure in VSS:
$\Prodcuts\Product1
...
$\Libraries\Library5
Question: Is this a logical structure to be using? If not, what should I do different.
Thanks in advance for your input.
Darvis
Question: Is it common practice for PRODUCT 1 to include project
references for Libraries 4 and 5 even though it doesn't reference them
directly (Yet one of its referenced projects does)?
Yes it is, it is even required for certain tasks, like code analysis in VS2010. The build process will exclude any directly unused reference anyway (not a reason for not cleaning it up, but it's kind of supported that not all the project references listed are used directly when building the project).
If you work in VB.NET, you can automatically clean the references (but you can easily break code analysis capabilities, and I encountered cases where it was just not working well), in C# the ability to clean project references is not built-in (certain (non-free) plug-ins do it like Resharper)
Question: Is this a logical structure to be using? If not, what should I do different.
(Maybe it should be a separate question on programmers, as it is kinda subjective, but I'll answer anyway :) )
I don't see any problem in your logic. Personally I don't split library projects and executable projects. They are just projects. It's really a matter of personal preference, others would split it by Clients, Platforms, etc. But as long as people can see the logic behind what you are doing, and I don't think you will encounter any more problem with it while using VSS.
Related
Just wanted to understand there are couple of code sharing strategies exist to achieve code reusable capability in Xamarin.
Which one should i use ?
Shared Project way OR Portable Class Library way ?
if you can explain with scenarios , it would be very helpful for me.
Thanks much.
Here is the Xamarin explanation.
The question is possibly duplicated but you ask specifically for scenarios.
If you ever wrote c cross platform projects, shared projects resemble the old-school way allowing you to use #if __IOS__ statements to run device platform code in your shared/common code files. A separate assembly is created for each target (say iOS or Android). They give advantages and disadvantages of each.
PCL generates one single assembly for the common code. PCL has some limited number .net features as shown here in this table. However, most of the important .net goodies are there as you can see.
Xamarin says that shared code method is easier but PCL is easier to compile a module and share or sell that with others.
When I make projects, I check what external plugins/components/ etc I want to use and make a decision based from. For example, you may want to use sqlite and there are different options for using shared and PCL projects.
I have a VS 2013 solution with one VB.NET ASP.NET project which references several c# class library projects (not DLLs) within the same solution. I made lots of changes to logic within some of the method overloads in one of the c# projects. Since the VB.NET project uses these overloads extensively, I want to see how many places these methods are referenced. I go to the c# project that contains the changes, right-click the overload I want, and select Find All References, but it only shows me the references in the c# projects. However, when I go to one of those methods in the VB.NET project, it finds all the references within the VB.NET project as well as the method declarations in the c# project.
I could do a solution-wide text search for the method name, but this method name is used multiple times because it's overloaded. Therefore, I want to search for a particular overloaded method signature, not the method name.
Is this a known shortcoming of VS 2013? Something else I've also noticed that I've noticed is that selecting Go To Reference from within a VB.NET project on a method that's declared in a c# project will take you to the object browser rather than directly to the method definition in the source project itself.
This is an old problem, there are many bug feedback reports for it on Microsoft's feedback site. The canonical one is probably this one. Quoting Dustin Campbell's response:
The general problem is that C# and Visual Basic do not share any common infrastructure with regard to the symbol tables that are used for features like Find All References, Go to Definition or Rename. So, such features don't work between multiple languages. That said, we are looking at ways to change this in the future, but the work required is very substantial.
Annotating a bit, the C# and VB.NET IDEs look similar at the surface but they are very different under the hood. Part of that is them being supported by distinct groups within Microsoft, a survival strategy for any software company, big groups don't work. But above all history plays a strong role in this, Visual Basic had strong IDE support for a very long time. They did not throw away that work when they moved to VB.NET, not in the least because they had to support all previous IDE features so not to alienate their existing customer base. The C# team got a fresh start without that baggage, they started from scratch. Inevitably the internals between them, like the IntelliSense symbol tables, are drastically different.
Tackling the "common infrastructure" problem was not forgotten, the Roslyn project was the instrumental step. It took a very long time to get finished but it is ready to go today. Integrated into VS2015. Whether it actually solves this problem is something I don't know yet, I will in a couple of months. Maybe somebody that has the RC version can confirm. They did create two versions of Roslyn, one for C# and another for VB.NET. Uh-oh.
I'm running VS2010 Version 10.0.30319.1 RMTRel
I've noticed problems compiling VB.NET application. When I "rebuild" the solution it reports the build was successful. When I then click the run icon to begin debugging, then the compiler will report build errors(often related to referenced projects). I've confirmed all the projects are targeting the same framework and after an undeterministic number of times repeating the same steps, it will eventually compile. This seems consistent enough to me with other code bases to believe that it's a problem with VS. Anyone have any thoughts that might help improve my experience?
You should also check your configuration manager - probably some of projects are disabled for building in current build plan.
is this a rather large solution? If so, the order of build may be out of whack and the way to solve that is to set the build order of the projects to make sure all of the dependent projects are built first.
One common reason is circular references. You cannot do this in a pair of projects, but it can be done if you cobble together a long string of projects. The way to catch this is a dependency mapping tool with a visual representation of dependencies. You will see the items that refer back up to the top.
We upgraded our .net 3.5 projects (c#) to .net 4.0. When you look at the project file there are two tags that I'm trying to make sense out of:
<RequiredTargetFramework>3.5</RequiredTargetFramework>
<TargetFrameworkVersion>4.0</TargetFrameworkVersion>
Why are there two seemingly similar tags with different values?
The <RequiredTargetFramework> element was already present in your 3.5 project. It's associated with the assembly <Reference> and only present on assemblies that are not available in .NET 2.0
I don't buy much stock in the single mention of it in MSDN, I don't see how batch building has anything to do assembly references. Nor is it used in any of the 3.5 MSBuild .target files. I think the IDE simply uses it to put the warning icon next to the reference in the References node when you change the Target Framework to a version less than what's needed to support the assembly.
There are other elements like this in a project file that don't affect MSBuild but have an effect in the IDE. Like <SubType> and <DependentUpon> in the <Compile> element.
Have you found this one link? link text. TargetFrameworkversion is easy, that's the one you can change in the project properties to say which framework to build against. The article says that RequiredTargetFramework is used to batch items (but it's still not clear on it' real purpose other than it's not used a lot)
batches the Reference items by their RequiredTargetFramework metadata. The output of the target looks like this:
Reference: 3.5;3.5
Reference: 4.0
Target batching is seldom used in real builds. Task batching is more common. For more information, see MSBuild Batching.
I know there are other questions regarding this subject, and I've looked at this question, but I'd like to see a little bit more discussion and information on both sides of this - is it a better practice to add a project to a solution and reference the project, or to add a reference to the .dll?
It's not much of a choice. If you have a solution with both projects then use a project reference. If your solution doesn't have the project then you have to use an assembly reference.
So the real question should probably be: do I create a solution with both projects? Yes, as long as the project is still in the debug stage and liable to require bug fixes.
If you only have the dll then you're stuck with a dll reference (obviously).
If you have the source then it's usually better to use a project reference. There might be cases where you have a utility library that's never going to change, but if there's the slightest chance of you needing a bug fix then having a project reference is going to make debugging a lot easier.
Summary - Project Reference by Project vs by DLL
Reference by project
code is visible
finds all references e.g. on a class (because code is visible)
better for testing (over all)
better for code redesign (impact)
Reference by DLL
code is hidden
separation between e.g. framework and project (for deliver of framework)
quicker compilation (because DLL is already compiled)
Well, project references are helpful when you are building and testing in both debug and release mode. If you directly add a DLL then you are locked into whatever that particular DLL was built as. The project reference allows this to be a build time decision.
Relative to your project architecture, you should always stick to projects within your problem domain. You should be using the GAC, if that is applicable to your environment.