We Keep Coding

How the same namespace works in a single solution with different projects

I have a MVC application(solution) having multiple projects in it. That is DaL, Utility, workflow etc...
In Dal, There is one namespace as " xyz.home.smart.Dal" In the namespace there is a Public partial "SqlEngine" class.
The same SqlEngine class(only class,No Dal reference; having same namespace) is included in the workflow project.
I have modified the "SqlEngine" Class in workflow and upon building I'm getting the Workflow DLL(work fine). However, along with this the other projects DLL are also building (note- I have not modified the "SqlEngine" in other projects).
How the DLLs are getting modified in other projects? Is it that, this is happening because of same namespace?

Namespace changes are not relevant to other projects.
Two likely causes for those builds:
Either you are doing "Build all".
Or these other projects depend on DaL (have a reference to it), so each time DaL is built they have to be built to make sure they aren't broken by changes in DaL.

Can we call methods of class from referenced dll without creating object?

I am new to C# and want some help regarding some small task.
I have two projects (Project1 and Project2) which are dependent on each other. I would like to call the methods from Project1 which is used as reference in Project2 without creating object of Project1. This means that I don't want to use Project1 directly because if I do so and some changes are made in Project1 I will have to recompile Project2 as well.
Can we create any intermediate project (say Project3) which will work as bridge between this two projects? So that Project3 can be used in some other task if needed. If this is possible then please let me know how?
I have stuck due to this.

Conflicting Project name with a Folder name in another project within the same solution

I've created a web application solution ABC in VS2013 which contains project ABC.
The current structure is as follows:
ABC Solution contains the following projects:
BusinessLogic
DataAccess
ABC project
ABC project contains the following folders:
BusinessLogic
DataAccess
I understand that this is a wrong way to design the project, but I have to deal with it as is in the time being. Right now I need to access the classes in the BusinessLogic project as well as the BusinessLogic folder from my ABC project.
I'm using this code to access the BusinessLogic folder classes:
ABC.BusinessLogic.MyClass MyFolderClass
But i'm not sure how i can access the BusinessLogic project's classes. The code below also ended up referencing the BusinessLogic folder.
BusinessLogic.MyClass MyProjectClass
How can I access the BusinessLogic project classes from within ABC project?

I believe that one way to do it would be to change the namespace's name, meaning. In the ABC solution, in the BusinessLogic project change the namespace to something like BusinessLogicFirst, so when you reference this project to the ABC project you'll have access with this code
BusinessLogicFirst.MyClass MyprojectClass
But for your own convenience change your naming because when someone else will try to maintain your code he'll have problems understanding your way of thinking.
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

I am not sure why you have kept such folder/solution structure, you must have some compelling reason(s) to do so. However here is an 'yes' answer.
By going to you project properties that is directly under your solution ABC, change the default assembly name and namespace (under Application tab) to something different and write a post build script (under build events tab) to copy the <>.dll to some specific path. And from there onward add a reference to that copied assembly to your project.

business layer code outside of Controllers folder gives compilation error

I've read in other posts that you can put the business logic in a VS2013 MVC project "anywhere", which I take to mean "possibly outside the Controllers folder".
However, when I create an App_Code folder in my project, and put business logic classes in it, (with the build property set to Compile, not Content) I get a compilation error, on the following, and the code editor intellisense won't recognize the the .Caching in the following:
using System.Runtime.Caching;
If I move the class back into a subfolder of Controllers, no problem, the .Caching appears in intellisense and no compilation error occurs.
Any explanations of why this might be so, and how I might adjust my project to allow business logic classes to operate correctly outside the Controllers folder, would be appreciated.

The App_Code folder contains code that is compiled at runtime.
See the following reference: http://msdn.microsoft.com/en-us/library/t990ks23.aspx
If you have business logic, it's probably best to put it into an external (from the webiste) library to increase reuse and enable better compartmentalization.

Add a business layer class library project to your solution, and then add reference to this business layer class library project to your MVC project.

First off, there's no such ting as App_Code folder for MVC.
Why?
Well, the App_Code concept is meant to work with Website Projects, however, MVC are Web Application Projects which is a framework or implementation of a pattern to work closer to the HTTP protocol and web requests and separate concerns into presentation (views), request handlers (controllers) and models. So, don't expect it to work with App_Code
Suggestion
Create/Add a Class Library project in the same VS Solution where you can keep all your business logic and then reference this project in your MVC app

Re-Building Each Tier [duplicate]

Project1 = Asp.net pages project (presentation Layer)
Project2 = Data Access Layer
when Project1 is hosted and running smooth, if i have to add few PRIVATE methods into the Project2 and call these methods within some of the PUBLIC methods that i know are being called by Project1, should the changes apply that i made in Project2?
I did the above, but the new methods were not called. (I think Project1 is still pointing to the old assemblies of Project2)
I am sure if i rebuild the Project1, the changes will work.
But if i have to rebuild Project1 after every change i make in Project2, what is the point of having the separate tier Architecture? I thought the good thing about separate tiers is that one can do as many changes in 1 layer, without rebuilding the other layers ... is that a wrong perception?

You don't HAVE to rebuild it. You can just copy the new project2 dll to the web app\bin directory and it will work if the interface hasn't changed. A build of project1 will redundantly rebuild project1 and produce the same result, and also include the latest version of project2, that's why it works, too.

First of all separate tier doesn't really mean separate assemblies. A multitier archtecture program can easily be stored in 1 assembly and have DAL, presentation and BL classes separated by some logical separator like namespace or even project folders with classes (or even no logical separation whatsoever, but you will known that certain set of classes is for DAl, and annother for BL, etc)
To your question - if your DAL is generic and has a fixed interface you can update your dal assembly ( for example fix some buggy methods, or something else) if you dont change interface of public methods. Obviously if you change some interface your other assemblies that reference this assembly will have to be not only rebuild but rewritten in order to use new method names for example