As a C# developer, I'm familiar with adding assembly references in a Visual Studio project. It looks like you can also add a database reference to a project.
My question is: Why would you want to add a database reference to a project?
Does this let you do something special like track dependencies on database tables or columns?
For SSDT projects such as you mentioned, there are two main use cases for database references:
Composite projects are a great way to handle cases where you have common schema elements such as tables that are shared by a number of databases. This maps to the concept of inheritance and object reuse in C#, and helps you avoid duplicate code and improve your design.
External database references are used when your code such as sprocs and views needs to reference elements from other databases. It is useful in resolving references and ensuring the project can build successfully. In this case it maps pretty directly to the concept of referencing Apis in C#.
Note that the help you linked to is the old help for VS2010 projects, more accurate help for SSDT is here.
Also you might notice that you can also add references to .Net assemblies, that may be necessary if you are writing SQL CLR code in your project and need to reference external code.
You cannot add a reference to a database project. The page you linked describes adding a reference to a database in a database project. The reference allows you to run scripts against the database within the project.
Related
I'm new to programming so I might not be using some of the correct terminology. I'm running into an issue with InteliSense when calling a C# class from another project within the same solution. It's not suggesting a using statement and is instead trying to get me to create a new class inside of the current project which is not what I want. I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
I looked at some of the documentation online and nothing has helped so far. InteliSense appears to configured correctly to suggest using statements. It provide suggestions just fine. I've been able to create lists and then use it to add the proper using statement along with some other things. Just doesn't want to work with anything inside the solution. I've been following a couple of different tutorials including, .net core 2.1 and 3.1, inside MVC and Razor page projects along with a couple just straight C# console apps. It doesn't work in any of them when I start adding multiple projects to the solution and try using classes from outside the current project.
I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
That is the correct behavior. In order for ProjectB to use classes defined in ProjectA, you must first add a reference to ProjectA. Just having the projects in the same solution is not sufficient.
The purpose of having multiple projects in the same solution is simply for grouping related code. The projects may or may not actually depend on each other. For example, a web application may have a separate projects for the actual web UI (the pages themselves), a data access layer, unit tests, maybe some class libraries for shared code used by multiple projects, and maybe even console applications (or some other project type) for performing backend administrative tasks. In this scenario, the web UI and console applications may have references to the data access layer project and/or the class libraries. The unit test project will have a reference to the web UI project, and so on. The dependencies are one-way - you may not have circular references (the unit test project has the web UI project as a dependency, but not the other way).
this might be a bit dummy question but I'm confused...
I have a simple C# solution in VS with 3 projects
UI
CORE
DAL
Now, I've added 'DAL' as a reference inside 'CORE' so now I can see and use my DB methods.
However, since I want to send one of the 'CORE' classes to my INSERT method which is inside 'DAL' (to insert the full object) I cannot see or access it, and I also can't add a circular reference and add 'CORE' to 'DAL'.
public void InsertOrUpdateResultData(MyObject _obj)
MyObject is from 'CORE' project.
Any help is appreciated.
Thanks
You can extract the common classes inside a separate project and reference it from the CORE and DAL. Eventually you can create DTOs.
If you encounter such situation you are probably doing something wrong. I would suggest to rethink structure of your solution. Maybe it would be worth to create another library that can be included in both CORE and DAL projects.
If you're using the same class across multiple projects, as is your case here.. have you thought about using a shared project? You can add the shared project to all other projects you need. Based on what you've stated, it would probably be a better solution.
http://dailydotnettips.com/2015/07/28/using-shared-project-across-multiple-applications-in-visual-studio-2015/
I have a MVC4 project which is going to be a large system, I want to split the database management into its own project so in my solution I will have MyMVC4 and MyMVC4_Data
I will add MyMVC4_Data as a reference to the main MyMVC4 project. I believe there will be multiple projects in the future so splitting the data makes sense.
My question is, what sort of project template will be sufficient for the database stuff, all it will have is Linq and manager classes for each table to insert delete etc. I don't think it would be necessary to include a new MVC4 project as the overheads will be too big for what is needed. The project must be referable by the main project
Any suggestions would be appreciated
Thanks
I'd use a Class Library project. From the docs:
You can use the Class Library template to quickly create reusable classes and components that can be shared with other projects.
When I need to add a reference towards a library, I've always been told to use the "add existing project" method, and referencing the project itself inside my solution.
But here in my new company, the use another method. They have a server which holds the compiled dll's, and keep versions of them so they can reference older versions when a change is too important to refactor older apps.
While I find this system really complicated (I guess there is a lot of work if a program pointing an older version of the dll is updated and needs some changes in this dll), they seem to find it pretty convenient.
What are the best practices for this? Linking the dll directly? Linking the project? And why? Any information is welcome!
Thanks in advance !
I usually take a copy of the compiled dll (if the source project is not available or if I don't need the source) and put it in a folder inside my solution, and then reference that. I check it in to source control along with my project.
I am of the opinion that you should be able to check out a project and build it directly from source control without having to go hunting dlls etc.
The Add existing project method is useful when you want to reference a library project which is develop side by side and you want to test/use it's types and methods and this (Add existing project) method will not be used to add the reference of pre-compiled (dll) files.
Read Project Reference (MSDN) article.
You would include it as a Project when you want to simultaneously work on the library. And that would happen mostly for small(ish) libs that will be distributed with your program (bin folder).
When an assembly is (going to be) installed in the GAC, and thus has its own release cycle, it makes more sense to reference the binary only.
Several combination of the above are possible too.
Adding Compiled dlls is mainly when the code is more or less locked (Architecture level code ) which you hardly ever changes
eg
1) communication layer(remoting/wcf)
2) Generic Gui layer (Wizards/dialog boxes)
3) Security layer (azman stuff)
you only need to change when your product is going to another direction say it uses to use .net remoting as communication now it will be using WCF
Using projects as reference when you are frequently changes referenced projects
also Visual studio works out nicely order of building the projects.
Although your company's approach is probably not very common among Microsoft developers, it is used rather successfully in the Java world. In the long run it is probably better controlled than any alternative, but without a fair amount of support scripts/programs (which, for instance, update projects/solutions automatically when needed) it can easily become unmanageable. In the Java world it is directly supported by tools such as Maven.
A lot of my projects contain the Castle/NHibernate/Rhino-Tools stack. What's confusing about this is that Castle depends on some NHibernate libraries, NHibernate depends on some Castle libraries, and Rhino-Tools depends on both.
I've built all three projects on my machine, but I feel that copying the NHibernate/Castle libraries is a bit redundant since I built Rhino-Tools using the resulting libraries from my NHibernate and Castle builds.
Right now, I include all projects in seperate folders in my /thirdparty/libs folder in my project tree. Should I simply just have /thirdparty/libs/rhino-tools in my project and use the Castle/NHibernate libs from there? That would seem to make logical sense in not duplicating files, but I also like having each project in it's own distinct folder.
What are your views on this?
This is one of the problems that we're trying to tackle in the Refix open source project on CodePlex.
The idea is that Refix will parse all the projects in your solution, and before your project compiles, copy the necessary binaries from a single local repository on your machine into a folder within the solution tree and point the projects at them. This way, there's no need to commit the binaries. Your local Refix repository will pull binaries from a remote one (we're setting one up at repo.refixcentral.com), and you can set up an intermediate one for your team/department/company that can hold any additional software not held centrally.
It will also try to resolve conflicting version numbers - Visual Studio can be too forgiving of mismatched component version numbers, leading to solutions that compile but fall over at run time when they fail to load a dependency because two different versions would be needed.
So to answer the question "how do you package external libraries in your .Net projects", our vision is that you don't - you just include a Refix step in your build script, and let it worry about it for you.
I use a folder for each, which seems to be the convention.
Does it really make a difference if you're copying them?
What if you want to switch one out? Let's say you go with a new O/R mapper. It will be much easier to just delete the NHibernate folder than to selectively delete DLLs in your Rhino-Tools folder.
Take this to it's logical conclusion and you won't have any folder organization in your lib folder since everything uses log4net :)
Add additional probing paths to your app.config files to locate the dependency dlls. This way your can get away with having just one copy of everything you want. Though there are some quirks to using this feature (you must create the folder structure in a certain way). Look here for more details on the tag.
I will definetly recommend having a thirdparty or vendor folder in each of your project trees. If you find it annoying to have 32 copies of the rhino-tools package, you can have a single copy of it in your code repository, and do external references to it in your project tree.
Lets say you are using SVN, you can make a repository called "thirdparty libs" and in this have versioned copies of the libs. You then make an external property on your "thirdparty"-folder in your project tree which then in turn automaticly will do a check out of your centralized thirdparty libs. This way you for instance only have to update in one place if a security or a bugfix comes out, but each project is still in command of choosing which thirdparty libs, and which versions to use.
About the deps internally in thirdparty libs, i wouldn't mind those. The first time you compile your project, and some of the libs arent copied to your bin-folder because of implicit dependencies you can add an external attribute into your bin-folder, which will then automaticly check out the missing libs. That way you still only have to update your thirdparty libs in one place.