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
Related
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
I have a class library lets call it UtilityLibrary.
I have a console application. So I right clicked on my solution and added an existing project (UtilityLibrary). I noticed that I can change the code of UtilityLibrary from within my console application.
The issue is if I had added UtilityLibrary to another application and the code had been changed it could causes issues. I was trying to avoid adding a dll reference so thought I would add a reference to my project however I am worried about the code being edited.
Have I added the reference to my project incorrectly?
If you where to check the Debug or Release folder if your console application you should see a UtlityLibrary.dll file, which would still mean that you are, in the end, adding a DLL reference (visual studio will do it for you).
Since you do not want to allow external entities to change your application, simply add a DLL reference instead.
Just to clarify, you can only change the source of one DLL from another application becuase visual studio can find the source files and makes them available to you.
No. You have done nothing wrong. And you can't just change the code of the compiled assembly. You are utilizing a feature from Visual Studio. Since you've build on this machine, and the PDB's are included, it can tell the assembly originated from that source code on your machine. So it allows you to edit it.
These edits don't come in the compiled assembly immediately, you have to compile it again in order to be in the assembly. (Note that you can extract the source code from any .NET assembly by using Refactor for example)
I'm about to start developing a desktop application (WPF) based on a "plugin" architecture, and was going to use MEF (and its DirectoryCatalog) to discover and load plugin assemblies. We're going to be developing many plugins, so it seems sensible to keep them in separate VS solutions rather than bloat the "core" application solution, but having only ever worked on single, standalone solutions, I suspect this is going to make debugging a bit tricky. I'm using VS2013 if that makes a difference.
I'm assuming that I'll still be able to step into a plugin in scenarios where the "core" application calls a method in that plugin? And I'm guessing that once in there, I'll be able to set breakpoints in those source code files that have been "visited"? But what if I want to add a breakpoint to a different source code file - one that hasn't been visited while stepping-through? How can I open that file? In a single solution I could just open it via Solution Explorer, but not (I'm guessing) when it's in a separate assembly.
I'm trying to pre-empt any problems I might have with this multi-solution approach, and wondered if VS had any clever features to simplify some of this stuff. Having separate solutions also means first compiling the plugin solution(s) that I want to test, then compiling and running the "core" application solution. While it's only a couple of extra mouse clicks, are there (again) any VS features that could help here?
This is a common scenario and not tricky at all.
In the project properties of your plug-ins, go to Debug -> Start Action and set Start external program to the executable of your core application.
This way, you only have to compile your core application once (probably using a build script that just builds everything), and debugging a plug-in will start the core application with the debugger attached and you can debug the plug-in (as soon as your core apllication loads the plug-in assembly).
Also keep in mind that you can dettach the debugger from the running application, switch to another instance of Visual Studio with another solution opened, and again attach to your running application. This comes in handy if you e.g. debug your plug-in and want to set or use existing break points in your core application.
As long as Visual Studio is able to find the debugging symbols (the *.pdb files), stepping through the code of e.g. your core application while debugging your plug-in is also no problem.
I see two ways to do this.
The more comfortable option:
1. You can add the external solution to the core solution.
Walkthrough: Adding an existing Visual Studio solution to another solution
By doing this you can organize your solution to reference the code and still keep each plugin solution separate at the same time.
You just reference those plugin solutions from your core solution that you currently want to work on. Also, using this approach you can organize the other solutions just like you would with normal projects and move thembetween virtual solutios folders to your liking until you have the most adequate folder structure.
Quote from the article:
The nice thing about this approach is that not only are all the
projects now in one solution but at any time, you can open the
separate solutions without impacting the "master" solution and vice
versa.
The files in the references solution can be opened and edited just like any other file from your "normal" projects, and of course, you can set breakpoint like in any other code file, too.
This way you can both edityour code and step through it, which I personally find much more convenient than switching and attaching to multiple processes.
2. Add the PDB files.
Put the DLLs with their corresponding PDBs of those plugins you want to debug into a folder and configure your core application to use that folder for the DirectoryCatalog. This enables you to step into the plugin code, but you will not be able to edit them.
#Andrew
Regarding debugging, it shouldn't be an issue as long as you drop the .pdb files with assembly in directory which you are using as DirectoryCatalog.
Regarding building plugin solution before Core- as you have 1 build file for each solution, you should check if you can write msbuild commands in a .bat file to get it executed one after other.
Besides all the above suggestions, another way to debug is to attach your addin solution to the running core process. Attach to Running Processes with the Visual Studio Debugger
I have a wpf Application in which I am trying to reference a class library i have created.
I have added a reference to the .dll
And i have added the using statement to my file, and the intellisense actually sees the new namespace.
Then in my code I am able to create new objects of classes in my added .dll just fine. the intellisense sees all the methods ect..no problem, no errors.
when I try to build my wpf application, all the sudden I get the type or namespace cannot be found error on my added dll.
Then i get errors whenever i am trying to create objects from that .dll.
I don't get what is happening.. why does it work before I build, but when I build it decides it doesn't know where that .dll is i am referencing?
Also i have gone to that class library i am trying to add, and mades sure it builds with no errors.
The most common cause of this is that your .DLL targets the full .NET Framework, but the WPF Application targets the Client Profile.
For example, if your library targets .NET 3.5, make sure your WPF Application targets the full .NET 3.5 or 4.0 framework, not the client profile.
A few thoughts on this matter that you can try:
Check that a lower version is not calling a higher version assembly (e.g. .NET 3.5 project is not calling a .NET 4.0 assembly).
Clean -> Build (or Rebuild)
Manually delete bin/obj folders of both caller and calling projects. This forces everything to be built - the 'hard ' way. This may sound redundant, but has worked for me a couple of times.
Restart VS - sometimes, there is just no explanation.
Reboot - when nothing else works, give it a break and try again.
You can Copy any .dll files from other project,
two .dll files.
eg: A.dll,A.pdb
and Rename this two files to your project's name.
Then you can rebuild this project.
If you're getting this without a DLL - just a code file check it's set to compile. In Visual Studio 2013 I keep adding code files and it sets the Build Action (found under Advanced section of Properties of the code file to "Content" rather than "Compile". Change this.
Sometimes an explicit naming of the assembly which contains the namespace is required.
xmlns:myns="clr-namespace:MyNamespace;assembly=MyAssembly"
I don't know why it is sometimes required.
I am using Visual Studio 2005, .NET 2.0
I am not really sure yet under what circumstances it happens, but here is the scenario:
I have a solution with a project structure like this: A library project Foo, a library project Bar which references Foo, and a library project Quux which references Foo and Bar.
Compiling fails with the Error message "Metadata file 'Foo.dll' could not be found" from Bar, and "Metadata file 'Foo.dll' could not be found" and "Metadata file 'Bar.dll' could not be found" from Quux.
Looking in my target directory (I have a combined target directory for all 3 projects), it is empty, so no project at all is compiled. Now I can get that Bar and Quux fail if there is no output from Foo. Problem is: Why does Foo silently fail? There is no error from it, and just building Foo instead of the entire solution works fine.
The "funny" thing is, after just pushing the build button again, the Foo.dll file appears, Bar no longer complains but does not produce any output file either, and Quux complains about missing Bar.dll. Pushing the button again, the Bar.dll appears, there are no more errors but no Quux.dll. Only after pushing the button yet again, the Quux.dll appears, once again with no errors.
The project dependencies are all set correctly, the solution build order says exactly the right thing.
I have even tried creating a new solution and new project files, then adding the sources again to those. No joy, either. Same thing happens.
I am completely stumped. Does anyone know a way out of this mess?
You should have separate output directory for each project. Each time a project builds, it clears the output directory, so it won't find any dependencies on the next one.
Don't fear losing any DLLs, they'll be copied on each bin directory where they are needed.
I think a work around to your problem could be using post build events that deletes previous version of your dlls and copies the new ones to your combined target directory.
When you set up the three projects to work this way, you will find that you are compiling each project to it's correspondent bin folder and to a combined target directory. There is a second thing you should do if you decide to work with this, set up for each project in your solution a reference path pointing to the combined target directory. Compiling order must still exist.
This way each project dll will be found in the combined target directory, each time you compile.
Although, this solution has it's own problems such as when a post-build event forgets to wrok properly; but it's rare.
Hope this helps
The problem is build order. If some project depends on another then that second project must be built first. Use build dependencies in the solution properties to overcome this.
Check you build order so that all seems right there..
Try to run a clean solution and build again is this when it happens?
Drag your project file into note pad and Find with "Import" tag
and replace that tag with this
Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"
Its should work
For reasons unknown, this happened to me with Visual Studio 2013 in the middle of a morning's work. One build, it was updating the dll, the next, it just wasn't, even though the build seemed to go smoothly. I finally addressed it by deleting the existing dll. With no pre-existing dll, the build had to provide a new one.
I agree that each project should have its own target directory. I have tried to get cute with this and it always causes more trouble than whatever I was trying to get around.
I have a vs19 , 5 project solution. I just added a new console app. THis app started suddenly compiling without complaint but did not produce files. the unit test project that depends on it complained.
I did the usual
clean / rebuild
clean / rebuild each project in order
check the project dependencies and the build order
restart vis studio (in know its 2020 and i still have to restart vs sometimes)
faced w/ the prospect of just creating a new project, i decided to try one other thing
removed all references to other projects
commented out all the code that depended on these.
i was left with pretty much a main() that returned a 0
this compiled and produced files
one by one i added the references back until everything was there.
uncommented the code.
at the end of this exercise things worked.
I can not tell you what changed.
Thought I would offer this as a trouble shooting method.