I am trying to learn to write my codes in libraries and compile them into DLLs in C#.
This is what I do:
I have a main VS project in which I piece up the different parts of the application that I am writing.
I write my classes in separate VS projects. Then, I compile them into DLLs, which I will copy the DLLs to the main VS project. The main VS project will make references to these DLLs and then use them in its logic.
The problem, however, is that when there is a bug or issues with the codes compiled in the DLL, it becomes very difficult to debug. The compiler won't tell where exactly the error came from. Also, when I make changes to the classes resided in the DLLs, I have to always recompile and replace them when working on the main VS project.
My workflow becomes very obtrusive this way. What should the correct workflow be when working with DLLs?
Add the DLL project(s) to the solution file which contains the main project and you will be able to break into that code with the debugger (right click solution -> add existing project).
Related
This question already has answers here:
What is the difference between a Shared Project and a Class Library in Visual Studio 2015?
(6 answers)
Closed 6 years ago.
What are the practical implications of adding a normal Project (WPF Application, Windows Forms Application, etc...) vs a Shared Project as a reference in Visual Studio 2015?
I know that Shared Projects are a rather new (since VS 2013) and presumably superior feature, so I would like to know all differences.
Could one difference be that files in the Shared Project can use code from projects where the Shared Project is added as a reference if all of those projects do have the code to be used?
This is not possible in a normal Project of course.
Also for some reason Visual Studio shows me far less suggestions if I do "Add -> New Item..." on a Shared Project.
As a sum up of differences found so far (take that with a grain of salt as I'm not an expert):
Shared Projects vs normal Projects (Class Library, WPF Application, Windows Forms Applications, etc...) added as a reference:
Files in Shared Projects can use code from projects where the Shared Project is added as a reference if all of those projects do have the code to be used.
Shared Projects do have less suggestions when "Add -> New Item..." as they are more generic.
Shared Projects are not compiled to .dll or .exe but added with source code to the project referencing them and therefore can be debugged step by step.
Project, assuming a class library, will be compiled and the dll will be referenced from the other project. Shared Projects are fancy way of file linking (or copy pasting the code file when compiling). This has benefits as in you can have access source code that is not only in shared project but also in the target project (as long it works for all referenced projects). But can also give conflicts if using this in an library that will be referenced in your target projecct too. I think you best can go for a normal class library and only use shared project if you are really sure you needed (was introduced to have better code sharing between your win8.1 and wp8.1 app)
I'm running into a bit of a strange issue. I have a Visual Studio solution with two projects in it. The two solutions are different languages, VB and C#. I recently learned that you can reference different projects, even if they are different languages, just as long as they're all .NET projects. This is very convenient as I'm basically making a plugin wrapper for a Windows Form project to be used as a plugin in another program. However, I'm running into a dependency issue while running the plugin within the host application.
Here's where things get weird. The original Windows form program (the one written in VB) is not written by me, however, if it's compiled to an EXE, it runs perfectly fine. However, I compiled it as a class into a DLL so I could reference methods from the plugin wrapper, written in C#. The plugin will work perfectly fine up until it attempts to call a method in the VB project.
I have the C# project referencing the VB project through the reference manager and the reference within the References folder set to "Copy Local" to have it copy the compiled DLL from the VB project with the plugin when it is compiled by Visual Studio.
What I am baffled by is the fact that independently, both of these projects function perfectly (in the sense that the plugin will not crash until it attempts to access methods from the other project), but as soon as I try to reference one from the other, everything falls apart. Am I missing something really simple?
I have a Visual Studio 2010 solution with a few projects, one of which compiles to a DLL and defines an interface to create a plugin. All these projects together make up a standard product.
Now, a have created another solution with a single project, that references that DLL and implements a plugin.
When debugging, I am running the standard product and load the plugin during runtime. Of course, I can debug all the code of the standard product, but how can I debug the plugin code?
It was way easier than anticipated. I just opened the .cs file I wanted to debug in the solution with the standard product and I could put a breakpoint there.
All in all, it Just Worked™ and I never tried this, because I thought it wouldn't.
Is it slower? Sometimes there are exceptions or issues triggered by open-source projects, where having direct access to the code can give you much more insight on what you're doing wrong. Does it slow down the project, and especially does it increase compilation time? Assuming no changes are done to the project - I don't think it needs to be rebuilt everytime?
Assuming no changes are done to the project - I don't think it needs
to be rebuilt everytime?
By default, If you choose Build, visual studio only considers the changed code. If you select Re-Build option then everything will be considered for compilation.
Does it slow down the project, and especially does it increase
compilation time?
If by slow you mean application execution performance, then NO, there shouldn't be any difference, and for Compilation time, yes it will increase a bit (if no changes are made to the reference project). If the project is referenced in multiple locations and changes has been made to the project, then everything should go through the compilation process to make sure that everything is working fine.
I personally prefer to have the project itself open (at least to start with). As long as you don't Clean/Build often, builds should only compile projects with changed code so there's only a minor difference in compilation speed.
run-time, there should be no real difference in speed assuming the version you have open is identical to the version in the DLL and that you do a Release build
That said, after I understand what's going on, I usually switch to DLLs to avoid clutter in the Solution Explorer and the additional memory usage in VS
If you are not going to change anything in the open source libraries. then it is an overhead. Because it will compile every time your are compiling your project.
Generally speaking you should use Project references when possible. This is from an old article, but I believe it still applies:
The advantages of using project references are:
They work on all development workstations where the solution and project set are loaded. This is because a project Globally Unique Identifier (GUID) is placed in the project file, which uniquely identifies the referenced project in the context of the current solution.
They enable the Visual Studio .NET build system to track project dependencies and determine the correct project build orders.
They avoid the potential for referenced assemblies to be missing on a particular computer.
They automatically track project configuration changes. For example, when you build using a debug configuration, any project references refer to debug assemblies generated by the referenced projects, while they refer to release assemblies in a release configuration. This means that you can automatically switch from debug to release builds across projects without having to reset references.
They enable Visual Studio .NET to detect and prevent circular dependencies.
Taken from:
http://msdn.microsoft.com/en-us/library/Ee817675%28pandp.10%29.aspx
I'm toying with my first remoting project and I need to create a RemotableType DLL. I know I can compile it by hand with csc, but I wonder if there are some facilities in place on Visual Studio to handle the Remoting case, or, more specificly, to tell it that a specific file should be compiled as a .dll without having to add another project to a solution exclusively to compile a class or two into DLLs.
NOTE: I know I should toy with my first WCF project, but this has to run on 2.0.
You can get away with just calling csc.exe on the pre-build event if you don't want to mess with the .proj file directly and add build events.
None that I know of using VS 2008 at the moment.
But you might want to check out NAnt. It is made for this kind of work.