hopefully this is a quick one. If I have c# class files on WebsiteA.com - can I reference them in WebsiteB.com? Both sites are on the same server, so I was hoping to reference them on a static address? (d:/inetpub/wwwroot/websiteA-com/app_code/MyClass.cs)
Is this possible? Or - do I have to copy the class file to WebsiteB.com and simply use that?
I just want to avoid repetition when I need to make any changes - avoiding changing both sites.
I've built both sites in .net 4 using visual studio 2010 express.
Thanks
If I were you, I would take all the classes needed by both websites and create a Class Library Project (DLL). Then reference that project in each website and use the classes. This means each site will be deployed with the same DLL but you will have a single project for common classes.
Hope this helps (I know it's not strictly the answer)
Sure you can.
I don't think that adding the class from the app pool of the IIS folder is a good idea though.
I believe it's a better practice though to make a class library as a separate project called for example Shared and reference it in both projects.
in Visual Studio you can "Add existing" then choose the "Link" option to add source code from another project
this can be much easier to manage than a shared class library - you can even include the same code in wildly different projects (compact framework, different versions of dot net, etc.)
Related
Even though Shared Projects have been around since Visual Studio 2015 (maybe as early as VS 2013 update2), I've only recently learned about them. Today I spent time trying to learn how to use them following a tutorial I found Shared Project: An Impressive Feature of Visual Studio 2015 Preview. However, the one thing the author did in that tutorial, which won't work for us, is he created the Shared Project and 3 other projects, all within the same solution. Of course, you can do that, but in practice we're likely to want to create a Shared Project in some solution, and then as time goes by, include that Shared Project in other solutions.
So what I did is instead of putting the Windows Forms application into the same solution as the author of that C# Corner post did, I created a new solution with a Windows Forms project in it, then I tried to add the Shared Project from the first solution. First, I tried adding the .sln file. That failed miserably. Then I tried adding the .shproj file to the second solution. That failed miserably as well.
Next I shared here on SO for ways of addressing this. I found 2 posts: Adding references in a shared (.shproj) project and How do I add a reference to a Shared Code project (.shproj) from another project. The second one gave me an idea. I decided I would simply add the Shared Project, from the first solution, to the second solution by clicking on the second solution within Solution Explorer, then doing a "Add Existing Project". That worked.
But I wonder, is that the way you're supposed to use Shared Projects? If so, it seems to me as though I could just as well created a simple class library in the first solution and then added that class library project to the second solution. Is there something about Shared Projects that make them inherently better to use, if you add the Shared Project to a different solution, instead of just adding a regular class library project to a solution?
A class library compiles into its own DLL and your original project references that DLL, whereas a project using a Shared Project will compile into a single assembly. One scenario I could think of with shared projects is that you can have single code base but has platform specific code sections marked by directives.
There is a good video on this subject even though it's being explained in the context of xamarin they do a good job i think.
https://www.youtube.com/watch?v=G5ov0gLZWgQ
Personally I I would always go with PCL (portable class lib) rather than SAP (shared project). I use shared code projects as documentation container in my projects. The project green icon stands out really well. I keep everything there from markeddown doc files to stored procedures and etc.
I'm writing a program in C# that has two classes, Foo and Bar. I have two executables that will use them, GenerateFooBar and SearchFooBar. My question is how should my solution be partitioned? From what I can gather, everything can live in one solution and each executable should have it's own project. Should Foo and Bar
share a project?
each have their own projects?
go with one of the other projects?
something else?
Thanks for the help! I'm coming from Java if that's helpful.
In your solution, create project called for example Common, and put all your classes and businbes logics there. Set project type as Class Library
Next add your other projects and in them Add Reference to Solution Common project to use it.
If multiple users are meant to work with the shared library, the best solution will be to create the local nugget
Create a shared project and put Foo and Bar into it. Reference that project from both executable projects.
If you later have many developers depending on the shared library you might make it into a Nuget package that you publish and have them depend on that.
From what I can gather, everything can live in one solution and each
executable should have it's own project.
Yes, you are right.
how should my solution be partitioned?
Totally depends on you and how you would like to manage it.
You could create one project, multiple projects, each separated projects, etc.
But, to reuse code as much as we can and to give a more structured way. Here is what you can do.
Make one Project which will hold the ApplicationServices, Helpers, etc eg: Foo and Bar.
Make Another Project which will hold the application itself (Could be two projects one for search and one for generate). You can add reference of service project to your foo and bar projects and to any other project you create in future.
So in the end you will have 2 or 3 projects (depending on you)
1- ApplicationServices
2- Generators/GeneratorServices/GenerateApplications/anyname
3- Search/SearchServices/SearchApplications/anyname
I have developed a lot of class library projects in VS 2012 to be used in Windows Forms and Web forms applications.
The question is simple. Do I need to deploy the DLL file itself together with the XML file that is created?
For example, the class library project is called DataWare. Upon building, I got 5 files in Release folder (this project reference Entity Framework):
DataWare.dll
DataWare.pdb
DataWare.dll.config
EntityFramework.dll
EntityFramework.xml
I know that ".pdb" file contains debugging information, so there is no need to deploy. The ".config" file is not taken into account. Instead the App.config or Web.config are.
Regarding this, I think I have to deploy just DataWare.dll and EntityFramework.dll.
However, the main doubt is if I need to deploy EntityFramework.xml as well.
Regards
Jaime
The XML file contains the doc comments for the public types & members in the assembly.
You only need it if you want Visual Studio to show documentation in IntelliSense.
If you're deploying a consumer-facing app (as opposed to a developer-facing reusable library), you do not need it.
No, in most cases you do not need it. If there is an external DLL that needs to be copied local and referenced using the config, then you might need to, but that is somewhat rare.
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.
Honestly, I can't word my question any better without describing it.
I have a base project (with all its glory, dlls, resources etc) which is a CMS.
I need to use this project as a base for othe custom bake projects.
This base project is to be maintained and updated among all custom bake projects.
I use subversion (Collabnet and Tortise SVN)
I have two questions:
1 - Can I use subversion to share the base project among other projects
What I mean here is can I "Checkout" the base project into another "Checked Out" project and have both update and commit seperatley. So, to paint a picture, let's say I am working on a custom project and I modify the core/base prject in some way (which I know will suit the others) can I then commit those changes and upon doing so when I update the base project in the other "Checked out" resources will it pull the changes? In short, I would like not to have to manually deploy updated core files whenever I make changes into each seperate project.
2 - If I create a custom file (let's say an webcontrol or aspx page etc) can I have it compile seperatley from the base project
Another tricky one to explain. When I publish my web application it creates DLLs based on the namespaces of projects attached to it. So I may have a number of DLLs including the "Website's" namespace DLL, which could simply be website. I want to be able to make a seperate, custom, control which does not compile into those DLLs as the custom files should not rely on those DLLS to run. Is it as simple to set a seperate namespace for those files like CustomFiles.ProjectName for example?
Think of the whole idea as adding modules to the .NET project, I don't want the module's code in any of the core DLLs but I do need for module to be able to access the core dlls.
(There is no need for the core project to access the module code as it should be one way only in theory, though I reckon it woould not be possible anyway without using JSON/SOAP or something like that, maybe I am wrong.)
I want to create a pluggable environment much like that of Joomla/Wordpress as since PHP generally doesn't have to be compiled first I see this is the reason why all this is possible/easy. The idea is to allow pluggable themes, modules etc etc.
(I haven't tried simply adding .NET themes after compile/publish but I am assuming this is possible anyway? OR does the compiler need to reference items in the files?)
UPDATE (16/05/2010):
I posted a similar question with a little more detail for question 2 on Experts-Exchange. I don't want to post all that info here as it just will be too messy but it explains question 2 in greater detail.
For your first question, you want to use svn externals. More details can be found here: http://svnbook.red-bean.com/en/1.0/ch07s03.html
For your second question, you need to create a seperate assembly and the easiest way is to create a new project within your solution. You can't have a single project emit 2 dll's (that I know of)
For your first question:
If the base project is a library then there is nothing stopping you from creating the following directory structure on your SVN:
Base project
Cool project nr 1
Cool project nr 2
All projects built on the Base project will include a relative reference and then everybody can checkout his Cool project X and the Base project and work on them. Checking-in changes for Base project will allow everybody else to see them by updating their Base project image. Advantage: only one SVN trunk required.
For your second question :
I tried my best, but I can't understand what you're asking :).