I have a Visual Studio 2008 solution with two projects in it. A C++ DLL and a Csharp application.
The Csharp application uses [DllImport] to access the functions in the DLL, and has a dependency set on the DLL.
For some reason, setting the dependency isn't sufficient to cause VS to copy the DLL to the build path of the app. So the app project has a post-build event which causes the DLL to get copied. (If anyone knows of a cleaner way of doing this, please let me know!)
The problem I have is that when I make a change to the DLL code, then attempt to run the Csharp application in the debugger, VS2008 fails to realise that the DLL must be rebuilt (and re-copied).
I have to force a re-build of the Csharp application (ie by explicitly choosing build, or by "touching" a .CS file).
Does anyone know how to tell Visual Studio to do the right thing?
Edits:
I am using project dependencies. They aren't working correctly.
I am using a post-build event to copy the DLL across.
The issue is that, if you simply choose to debug the application, Visual Studio fails to recompile the changed C++ project, despite the fact that there is a dependency in place.
I know the dependency is working, because if I choose "Build" (as opposed to "Debug") the C++ DLL is built.
"Build" and "Debug" do different things. In Tools - Options - Projects and Solutions - Build and Run, there is a checkbox "Only build startup projects and dependencies on Run". This is checked by default. So, if VS isn't recognising the DLL as a dependency, it won't build it when you choose "Debug".
I don't have VS to hand (only Express), but you could try adding the C++ DLL as a reference rather than a dependency.
Hmm... so I haven't done this exact thing before but I just threw together a C++ lib project and a C# winform project in the same solution. I right-clicked the solution, chose Properties and then under Common Properties->Project Dependencies, I made the C# one depend on the C++ one.
When I make a mod to the C++ one, it will ask me if I want to rebuild the C++ one. There's a "Don't ask me" checkbox too.
Maybe my test is different than your situation, but it seemed to work when I did that.
Hope that is some help.
Assuming the DLL project isn't used in another solution, why not put the post-build event on the DLL app project, so it is always copied?
I've not tried, but can't you do this with the build order?
I have experienced this same issue with applications that have DLL project dependencies. It seems to me that the problem is that Visual Studio only launches the post-build event if it has to recompile something in the Application's project. So, if you modify the DLL source without modifying any of the headers that the Application includes, then the Application is not recompiled because from it's perspective the DLL is the same. Since the application is not recompiled, the post-build event is not triggered. So, the Application is left with out of date DLLs. I have yet to come up with a good solution to this problem.
Related
I'm a bit of a noob on that topic so I'm searching for help. I need to install this library (https://github.com/twcclegg/libphonenumber-csharp) for a unity project where I need to check phone numbers.
But as I always made simple games in unity I really don't know how to do that and I don't really know either what to search to find an answer.
If anyone of you knows how to do it, it will really make my day.
Thank you
Once do a build on a project you want to use in Unity, then find the DLL output from the build. I recommend you do Release Builds, but for now if you are not familiar with Visual Studio just use what you were able to build. If there are multiple directories then you only need one - the best one to use would be any labelled ".NET Standard" which it seems you have a .net standard 2.0 directory.
Go to your Unity project in the Assets folder, and if there isn't already a Plugins folder create one. Then in Assets/Plugins create a folder named whatever you want for the library - in this case PhoneNumber would be fine. So you would have Assets/Plugins/PhoneNumber and you would copy/paste the contents of your NetStandard2 folder there.
In the end you should have Assets/Plugins/PhoneNumber/PhoneNumber.dll
As soon as you have that dll, you can switch back to Unity and see if it worked by checking the Unity Console for any Errors. You might receive errors saying it could not load the DLL. Almost always if it can not load the DLL it is because of missing dependent DLLs - which is why I said to copy the entire folder contents inside the "NetStandard2" folder since it may contain more than just PhoneNumber.dll - it may have it's necessary dependent dlls also.
If not, you can read the error output and hopefully get a clue as to what dependent dlls are missing. You can also expand the Dependencies in Visual Studio.
Typically the DLL failing to be loaded in Unity is because of missing dependent DLLs. Expanding the Dependencies, which is found under the project name in the Solution Explorer window on the right side of Visual Studio, will show you what libraries it requires. Most of what you see under dependencies (if not all) will require a similarly named dll. Under the netstandard2.0 dependency I see System.Collections.Immutable - so you may need a System.Collections.Immutable.dll which should (usually) be in the output folder when you build the project. You would also need that dll in Unity in your PhoneNumber folder along with PhoneNumber.dll
I have a (mostly C#) solution that needs to build in x64 because I integrate with a C++ project, so I had to choose a platform.
I noticed that my code changes don't always show up at runtime and I found out that when Solution is Debug x64 it compiles the changed project but does not copy the dll to the bin of the startup project, so the debug session uses an older version of that dll.
I tried most variations of building, and the dll-copy never happens, except when I rebuild the startup project, or the solution, obviously...
When on AnyCpu, all works perfectly all the time. So, alternate solution: maybe I can use the C++ project and keep my C# projects on anycpu?
All projects are enabled in the solution config for both anycpu and x64.
Any suggestions I could look out for?
Because the problematic project was a dependency of a dependency of the startup assembly, I tried adding a direct reference to it from the startup project. The issue disappeared...
Of course, I prefer not having refs that aren't really necessary, so when I removed that new reference again, it kept working. So, now I cannot simulate the issue anymore.
Using git the only change I can see is that the ProjectReference is now a lowercase guid, and it was uppercase... This probably happened when I gave re-referenced the project a try earlier... odd stuff shrug
I am using Visual Studio Professional 2010 and the Team Foundation Server Express (beta). My VS Project (C#.Net / WPF) has been migrated from VS 2008 (without TFS) to VS 2010 (with TFS).
Whenever I apply changes to my code and try to debug my application, I get messages like This breakpoint will not be hit. (in german: Der Haltepunkt wird momentan nicht erreicht. Der Quellcode weist Unterschiede zur Originalversion auf.) and the project is started using the old executable version (the one with the last successful build). No errors occure, the code is OK, but the changes are not applied either.
When I manually cleanup and rebuild my project, everything works quite fine - but there has to be a fix for this issue?
Edit: I just added a new project to my VS solution and checked it in on the TFS Server. Using this new project the problem does not occure. Even when I add the same dependencies I used in the project mentioned above, the debugging and building of the new project works fine without the errors mentioned above.
Maybe this information helps you to lead me to a solution.
It's not clear whether existing answers are not sufficient. I can't know exactly what's causing your problem; but, I can detail some places this potentially comes up.
The first area that I commonly see this is when a project references an assembly directly. You can create a project that creates an assembly. Another project might use that assembly and you can reference by assembly directly (and not add a reference to the "project"). This disconnects VS from really knowing it needs to "build" that referenced assembly first and it will sometimes get out of sync with the debugging symbols (PDB). You can tell if a project has been referenced or an assembly has been referenced in the properties of the reference (expand References in Solution Explorer, right-click a reference, and select Properties). A referenced project will not have a Specific Version property, while an assembly reference will. You can sometimes also tell from Project\Project Dependencies. If you have a reference to an assembly generated by another project but that project isn't a dependency in Project Dependencies, it might be an assembly reference. To fix this, you can usually just delete the reference and add a reference to the project.
I've also find that sometimes breakpoints confuses the debugger. If I have many breakpoints or they've been kicking around a long time, the debugger sometimes does some weird things. If I delete all the existing break points (Debug/Delete all breakpoints) and re-apply them the debugger is usually much happier.
You can find the answer here. The assemblies might be in GAC or a project or some projects need to be rebuild to generate the pdb files again, which are used for debugging. If you don't choose to rebuild it might use the old pdb files.
My guess is that you are putting breaking points somewhere your program can't access them.
Ex:
const int x = 5;
if(this.x == 1)
//do sth <--- breakpoint here
If you are running a mixed mode application (unmanaged native C++ & managed C#), make sure to set Enable unmanaged code debugging in your C# application's Properties window.
You have to rebuild, there isn't an easier way around it.
The program database files (PDB) need to be recreated. You should also have your configuration setting set to debug.
Also the first answer to this question must be of help as well.
This happened to me when I started VS as an admin, and it also happened to me when the project is set to a different architecture than a DLL that I used in this project.
I have a Visual Studio .Net Solution which has many projects/libraries.
When I work locally on my own PC there is no problem as I tend to recompile those libraries that I have just changed and everything is in sync.
The problem is sometimes other developers who once in a while require to work on or look at my code have an enormous problem recompiling everything.
In the configuration Manager, I do not have all projects checked else it would take too long to build everything whislt working.
Problem is when the solution is compiled on another application, some of the errors reported say a particular library has error and its taking too long to figure out all the dependencies compiling each one individually.
Even when checking everything in the config manager it still does not seem to compile correctly.
I thought when you add a reference to a library the dependencies are taken care of.
Is there a simple way to make sure the solution determines what are the correct dependencies and make sure everything is built in the correct order?
Thank you
After other developers got new source codes from you, they should close Visual Studio and reopen the solution.
Sometimes there are also troubles with dependencies in Visual Studio. First, try these menu commands:
Build > Clean Solution
Build > Rebuild Solution
This will show you which dependencies are cyclic or not correct.
Also, in Visual Studio project must not depend on another one which creates executable (at least for our pure C++ -written project this is true). I.e. "Utils" project which compiles into "Utils.dll" cannot depend on "MyApp" project, which exports some functions or symbols and compiles into both MyApp.exe and MyApp.lib (or some other kind of assembly). If you have such a dependency, you must correctly setup project build order and manually set MyApp.lib as in linker inputs.
You can package and distribute your assemblies using http://nuget.codeplex.com/. It's made to solve this problem.
I just upgraded a solution from .NET 2/Visual Studio 2005 to .NET 3.5/Visual Studio 2008.
I have a Web Application Project "W" that has a project reference to a class library project "C".
When I build "W", "C" is compiled and copied local, and all is good.
However, if I make a change to C, or build C with a different configuration, and compile ONLY C, the output is automatically copied to W's \bin directory! And in my case, this breaks W.
This behaviour seems to be specific to VS2K8 and web application projects. I'm sure someone thought it would be nice to have studio push updates forward to referencing projects, but it's a very bad idea.
Is there a way I can turn this behaviour off? I can't find a related project or IDE option anywhere.
Create a file called "Libraries" or something else appropriate and put a copy of the DLL file from your class library project into there and have the web application project reference that file, as opposed to the project.
This will allow you to modify your class project at will, but will also force you to copy things over to make sure you have the latest and greatest in your web application. In your case, this sounds like the preferred method for you.