I've searched on google and here quite a lot for my problem and can't seem to find a solution.
I have this huge solution, one of the projects(let's call it "Main") have reference to two other projects(A and B). Projects A and B have a reference dll from an external tool, it's the same tool, but different versions of it. The developer must have the tool installed in the computer to be able to use it.
Now, Project A uses Tool_v1.dll, and Project B uses Tool_v2.dll. If a developer has Tool_v2 installed, they can build the Main project with no problems, but if he has Tool_v1, the old version, he can't build Project B for obvious reasons.
My idea to solve this(as a developer with old Tool_v1 installed) was to make two build configurations in VS, but just having the Project B's referenced, even if not used, still causes it to be built, thus giving errors when I want to build the solution.
If I simply delete Project B's reference works like a charm, but I wanted to simply choose the build configuration it's and done. Any ideas?
You can create two different configurations, each with specific reference lists/locations.
I have detailed instructions on how to accomplish this here: https://johniekarr.wordpress.com/2013/12/25/configuration-specific-reference-location/1
Related
I have an issue including a self-built library to a C#-project. I have created an own class library called ClassLibrary1 just to learn how to add libraries on Visual Studio 2019.
So I have written some simple code in a newly created .NET-class library project and have clicked on "create new solution" (directly translated from my german IDE-language. Maybe it's called slightly different) after writing the code. Back in the C#-project, I have selected the dll-file from bin/Debug/ of the class library's project folder.
After I have set the checkmark, the dll-file was shown in the solution-explorer under Assemblys like expected. But the issue I now have is that I still cannot use the ClassLibrary1.dll-file in the cs-file in this very project as I expected via the command "using ClassLibrary1;". It only shows me the error message "type- or namespacename "ClassLibrary1" not found" when trying to compile the C#-project and I don't get, why this is the case.
It seems like it has to be a very obvious problem but after some research on the internet and trying some things by myself still nothing has changed.
Thanks in advance for helpful replies.
The by far easiest way to manage a library is to use project references. Ensure that your library and the project that uses the library is in the same solution. Then right click the "references" and select "add Reference", go to the project tab and add a checkbox for the library. Read more about managing references.
You might also need to add namespaces for the classes you wish to use in the source files.
I would not recommend managing using file-references to lose dll-files, since it can easily become a hassle to manage. I.e. if you create a new version of the library you would need to build, and explicitly replace this file in all other projects and update all the references.
If you want to share libraries between multiple solutions the more popular solution would be to setup a nuget server. This solves some of the updating problems by maintaining multiple versions of the same library, and provides a nice interface to update references in all projects. But this is a somewhat more complicated solution, so I would not recommend this for new developers.
we are working on many different applications where each application has its own VS solution (and of course a CS project). Additionally there are many libraries (also CS projects) that are shared between the applications and are included in the VS solution so that you can debug during startup phase of the development.
We also have a "master" solution that contains all projects in one big solution for refactoring issues. Because VS does not support "solutions in solutions" we have to maintain also this master solution. We are talking about 300 assemblies.
Now a point is reached where it's helpful anymore to have all CS projects as ProjectReference in the application solution anymore. For example we have a library that does the CUDA support which can be compiled once and then used as a regular Reference.
The only problem here is that there are occasions where you need the ProjectReference back again when you need to debug into a problem that can only be verified when it runs in conjunction with the main application and cannot be verified in a normal test case.
One option would be to maintain two projects, one for debugging and one for working. The only problem is that once you debug and you need to use the ProjectReference the dependencies cascade down the whole project tree.
For me it feels like that I need two CS projects for each project. One that only contains References and another one that only contains ProjectReferences. Mixing could be a problem. The question is, if there is something automatic where a Referency-only project can be created from a ProjectReference-only project?
How do you solve something like this?
In my solution we have projects both in c#, that controls some GUI and networking work, and c++, that manages some hardware interactions. In my c# project I have the proper PInvokes and am able to use the c++ output dll with no issue but in order to do it, I have to manually copy the output dll to the build directory or create a build script that manages the copy.
My issue with this method is that the solution, in reality, has many many projects, something like 150 at the moment, covering c++, c, c#, and vb.net. We create and delete projects all the time and managing the copy scripts is becoming a major pain. Especially since not all of the projects rely on each other and we have like 20 different build configurations.
Is it possible to simply have the c# project reference the c++ project and automatically copy the project output the same way it does with other managed projects without using post build scripts?
Well, the way I do it and have always done it is by obviously using Visual Studio, and assuming this C++ projects are VS projects you can easily create a VS Solution containing multiple projects that you can organize with "Solution Folders". The organization of your projects inside the solution is really up to how you want to organize it. It resembles a file system with nested folders. Needless to say that you can host projects in different languages such as C++, C#, VB...I'm not too sure if you can include a C project or not, that's out of my expertise.
See a screenshot below of a solution I created to demonstrate this...
Notice that "Business" has a nested solution folder (Utils) which contains a C++ project (ERM.CPPLibraries) and a VB project (ERM.VBLibraries). Then if you reference projects within the solution (Right click -> Add Reference), you will not need to copy the output assemblies everytime you compile your solution (or project(s)) VS is smart enough to resolve all dependencies, resolve them and update them.
Hope it gives you an idea
Edit based on comment
In simple words...No, it's not possible to reference a unmanaged project from a managed project in a VS solution. You can reference DLLs but not projects itself
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instance for each library and application. After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
Would like to understand why this happens and if something can be done to make this work more smoothly?
Not sure if it's relevant but most of my applications I write in VB.NET and libaries in C# (as I'm in progress of changing everything to C#). I also have C# files from the libraries open in the consumer application VS, as it pops up during debugging. I also reference library dlls in the library project /bin/Debug folder, because I'm making a lot of changes at this point of development.
Warning 1 Namespace or type specified in the Imports 'somelibrary'
doesn't contain any public member or cannot be found. Make sure the
namespace or the type is defined and contains at least one public
member. Make sure the imported element name doesn't use any
aliases. 'local path'
..
Error 72 Unable to load referenced library 'path\somelibrary.dll': The
process cannot access the file because it is being used by another
process.
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instances for each library and application.
This is the fundamental source of your problem. Visual Studio does not like it when things outside it's control change. You should have a single solution open with all the relevant projects included in it. Then when something changes, all the projects which depend on that project will automatically be rebuilt. (At least, that's the default.)
After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
I don't think it has anything to do with how many times you clean and rebuild it, but how long it's been since you last made a change - you have to wait long enough for the VS instance building the dll to release the lock on the file, before the VS instance that is using it is able to access it.
When you build a project you lock up the .DLL file in the project you build it from, because that is the version of the assembly that the library instance of visual studio will use - however you are referencing that very same library in another process hence the reason you are seeing the error.
You have two options, keep having two instances and then close the two instances open them again and it will be fine.
What you are better off doing is adding the project itself you are referencing (and are getting the error for) to your solution. Then instead of referencing YourProject/bin/debug/assembly.dll add a reference to the local project via the Projects tab. This will then keep one process referencing the appropriate assemblies that it needs.
For every project in the solution check the project settings -> Compile tab -> advanced compile options... -> target framework(all configurations), see if they are all (for example) .NET framework 4. having different or the wrong framework might cause the problems you're having right now
Situation
I run a build system that executes many builds for many project. To avoid one build impacting another we lock down the build user to only its workspace. Builds run as a non privileged users who only have write ability to the workspace.
Challenge
During our new build we need to use a legacy 3rdparty DLL that exposes its interface through COM. The dev team wants to register the build(regsrv32.exe) but our build security regime blocks this activity. If we relax the regime then the 3rdparty DLL will impact other builds and if I have two build which need two different versions I may have the wrong build compile against the wrong version (a very real possibility).
Question
Are there any other options besides registration to handle legacy DLLs which expose their interface via COM?
Thanks for the help
Peter
For my original answer to a similar question see: TFS Build server and COM references - does this work?
A good way to compile .NET code that references COM components without the COM components being registered on the build server is to use the COMFileReference reference item in your project/build files instead of COMReference. A COMFileReference item looks like this:
<ItemGroup>
<COMFileReference Include="MyComLibrary.dll">
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMFileReference>
</ItemGroup>
Since Visual Studio provides no designer support for COMFileReference, you must edit the project/build file by hand.
During a build, MSBuild extracts the type library information from the COM DLL and creates an interop assembly that can be either standalone or embedded in the calling .NET assembly.
Each COMFileReference item can also have a WrapperTool attribute but the default seemed to work for me just fine. The EmbedInteropTypes attribute is not documented as being applicable to COMFileReference, but it seems to work as intended.
See https://learn.microsoft.com/en-ca/visualstudio/msbuild/common-msbuild-project-items#comfilereference for a little more detail. This MSBuild item has been available since .NET 3.5.
It's a shame that no-one seems to know anything about this technique, which to me seems simpler than the alternatives. It's actually not surprising since I could only find just the one above reference to it on-line. I myself discovered this technique by digging into MSBuild's Microsoft.Common.targets file.
There's a walkthrough on registration-free COM here:
http://msdn.microsoft.com/en-us/library/ms973913.aspx
And excruciating detail here:
http://msdn.microsoft.com/en-us/library/aa376414
(the root of that document is actually here: http://msdn.microsoft.com/en-us/library/dd408052 )
Also, for building in general, you should be able to use Tlbimp or tlbexp to create a TLB file that you can use for building, assuming the point of registering is just to be able to compile successfully, and not to run specific tests.
Installation tools such as Installshield can extract the COM interfaces from the DLLs and add them to the registry. It can also use the self-registration process of the DLL (which I believe is what regsvr does), but this is not a Microsoft installer best practice.
in .NET COM is normally done thru Interop in order to register .DLL in .NET they are called Assemblies and that can be done several ways.. by adding references via VS IDE at the project level, or writing code that Loads and unloads the assembly.. by .Config file that haas the reference to the assembly as well as the using of that reference within the project... GAC.
If you have access to the 3rd party .DLL's you can GAC them, and reference them in your project
you can add a using to your .cs file header as well as add the reference to the project by right clicking on reference --> add Reference ...
you can also do the above step as well as set the copy local = true in the properties for that .dll.. I hope that this gives you some ideas.. keep in mind that .NET assemblies are Managed code so there are several ways to Consume those 3rd party .DLL's using other methods within C# like LoadFromAssembly ect..
Thanks for all the help.
We changed from early-binding to late-binding because we never really needed the DLL at compile time. This pushed the registration requirement from the build server to the integration test server (where we execute the installer which handles the registration). We try to keep the build system pristine and have easy-to-reset integration systems.
Thanks again
Peter