Summary
I'm having a very strange behavior with Visual Studio 2010, and I'm not sure if it is a bug or if there is some twisted logic to why it is behaving in this way.
The executive summary is that when I use Batch Build->Select All->Rebuild to build all the configurations for all my projects, VS2010 produces differing output binaries depending on what is the currently selected Solution Configuration. This is really annoying because some of the project outputs fail to run correctly (giving a "[Project name] has stopped working" error dialog on startup) depending on which Solution configuration was selected during the batch build.
More details
I have a Solution with 3 C# projects in it (1 .dll outputting project, referenced by the other 2 .exe outputting projects). Of the .exe outputting projects, Project A has Release and Debug Project configurations. Project B has a Debug, Release-x86, and Release-x64 configuration because it needs some different post-build scripts run to give it the correct version 3rd party libraries.
I have 4 Solution Configurations: Debug, Release, Release-x86, and Release-x64. Release-x86 and -x64 are set to build only Project B. Release and Debug build Project A and the shared dll project.
If I select the Debug Solution configuration from the current configuration drop-down box, and the Batch Build all, then when I try to run the Release configuration of Project A it fails to run. If I select any other Solution configuration from the drop down, and then Batch Build all, then it runs successfully. When I diff the produced .exe file, I can see that it is different between these two cases.
Question
Is this some known intended behavior of VS2010? If so, can someone give a hint as to why this problem may be occurring and how I can fix it? Is this a bug in VS2010?
Follow-Up Clue? [Edit]
Could this have something to do with how VS2010 handles "Project references"? As I mentioned, both .exe projects reference the dll Project, call it Project D. I added that reference (to Project A, say) by selecting Add Reference -> Project -> Project D. But of course the different configurations of Project A want to use different configurations versions of Project D. When I examine the Project A -> Project D reference under Properties, I see a Path field that is not editable. Depending on which Solution configuration is selected, I either see ...\Project D\bin\Release\Project D.dll or ``...\Project D\bin\Debug\Project D.dll, and I don't see any way to control this so I guess VS2010 is trying to be smart about picking the details of Project configurations. But even more strangely, if I select Batch Build -> Select All -> Clean to remove all compiled files, than these reference paths change to ...\obj\... instead of ...\bin\... when I inspect them, and I can't seem to change them back except by removing and re-adding the project reference.
Follow-Up 2 [Edit2]
I lied a little bit earlier, I actually have 2 .dll projects (Projects D and E, say) where D references E through a project reference.
I'm pretty sure something broken or bizarre with Project References in VS2010 is the culprit, and think I have found the root cause of the selected-Solution-Configuration-dependent behavior, with the following steps
1) I Batch Build -> Select All -> Clean, to remove all previously compiled binaries.
2) I select a Debug Solution Configuration from the drop-down.
3) I Batch Build -> Select Only Project A Release -> Rebuild.
By watching the Output window, I see that VS2010 knows that Project A depends on D, and D depends on E, so it attempts to build them in reverse order. It successfully builds the Release configuration of project E. But then it tries and fails to build the Release configuration of project D, because it complains about missing the missing Debug version of E dll file. And likewise A fails to build because of the absence of the Debug version of D.
So it seems that the selection Solution Configuration is overriding the configuration of referenced projects in Project to Project references.
Is that supposed to be the case???
After some further searching, I've found that this is a known bug in VS2010, marked as "Wont Fix" by Microsoft. Batch Build in VS2010 is simply broken. If you think that's as dumb as I do, go ahead and express yourself to them.
https://connect.microsoft.com/VisualStudio/feedback/details/556158/batch-build-links-to-wrong-referenced-projects
Related
I have two solutions, solution1 containing project1 which generates a source file that is compiled into solution2 (having project2). You just build and run solution1, then build and run solution2.
Some of my team members are complaining about the usability of this, so, i've put both projects in one solution, and set them both to run (multiple startup projects). I put a pre-build step in project2 to wait for project1 to finish running, so project2 will be build with the latest code generated when project1 runs.
The trouble is, it doesn't work! Visual studio builds project1, and project 2 is waiting for it to finish running (because then the code project2 needs is generated by project1). But Visual Studio apparently doesn't run any of the projects until they are all done building, so this 'wait for project1' keeps project2 from building (by design) but also keeps project1 from running (although it wouldn't have to).
Is there any way to get around this and perform the functionality I want, or a codearound/workaround?
Visual Studio calculates the build order according to your dependence. If project A depends on project B, Visual Studio will build B prior to A.
In order to change build order just right click the Solution node and select
"Project Build Order"
Edit by O.P.:
This fixed the build order but didn't completely solve my problem. It did lead me directly to the solution so I'm editing the answer to make it complete (instead of a comment).
In order to cause it to run Project1 to generate the code, I had to insert a post build step (compile, build-events button in lower right) which was just the name of the assembly (project1.exe). This ran project1, which edited the file that was part of project2, which caused the make logic to see that a file in project2 was newer than project2.exe, kicking off a rebuild of project2 as a bonus. Now you just make the changes to either project, run it with F5, and Boom, it just works, nobody's the wiser I'm generating code.
Just have the two projects in the solution. Set the project 2 as the only Startup project and reference project 1 using a project reference. You can then set the project 1 to always build using the configuration manager in Visual Studio. Project 1 will always be rebuild first as you build/run project 2.
Edit: Also make sure your project dependencies are set up so that your project 2 is dependent on project 1. That's in the menu item Project -> Project Dependencies.
Why was this down voted? It does exactly what he wanted. Just set the build location for the project 1 to the location his project 2 is referencing. I would imagine his resource folder, where ever... It will rebuild his project 1 before rebuilding his project 2 with the most current assembly for project 1.
I'm adding my dll file to my reference and set Copy local to true
Everything is OK and after I build application, my dll added to output folder
Now my question is how do Ι change the local path?
For example:
my application path is C:\myproject, I want to put dll into C:\myproject\libs
How can I set dll path to {applicatonpath}\libs NOT {applicationpath} ?
When you compile you project, visual studio will put everything that has been compiled and set to copy locally to the "output folder", which depends on your current compile configuration. If you are compiling in Debug mode then this folder will be:
c:\your_solution_path\your_project_path\bin\Debug
If you use Release mode, it will be:
c:\your_solution_path\your_project_path\bin\Release
However, sometimes we reference a lot of assemblies (DLLs if you will) and those assemblies have dependencies of their own. In order to make everything "point and click" for our convenience, we must tell visual studio how we would like it to act for a particular project build.
So, as TotPeRo said, you should go do project properties and use the functionality of Pre-build and Post-build events. As the name suggests, Pre-Build happens before the actual build, while Post-Build takes place immediately after it. Please refer these links for further information: link1 and link2.
Lets assume the following scenario:
You have one solution.
that solution holds 2 projects (let's call them Project A and Project B). Project A is the actual GUI. Project B is just a helper project, that compiles into a DLL.
Let's say, that project B is doing some heavy matrix calculations, so you also have to include some MatLab libraries. NOTE: only Project B uses these libraries.
Project A references project B so that you can use the calculated information from B and show it in gui in A.
In order to compile this, the compiler is smart enough to determine, that Project B should be compiled first. If everything checks, the project is compiled into ProjectB.dll. Then, the compiler proceeds to compile Project A. It check all the dependencies and finds out, that you have already compiled Project B (which is a dependency for Project A) and that it can continue. Everything is then copied to the output folder (bin/Debug or bin/release) and should be in working order.
However, during runtime, something goes wrong and the application crashes. You find out, that Project B does not have the appropriate library to work with (namely MatLab libraries). And then you conclude, that MatLab should be included in the bin/debug (or bin/release) folder at compile-time. Since the MatLab library is a dependency library for Project B but not for Project A, it does not get copied and hence the exception. You can mitigate this behavior with the aforementioned Pre and Post-Build events. You can tell the Visual Studio that you want it to manually copy MatLab.dll to the output folder when it is doing a compile. This comes super handy when you come into situations like these. Build events can also trigger a lot of other things so be sure to check it out. I'm using this a lot and it's a time saver at least.
in the Visual Studio you can go Project > [project name] Properties > Reference Path
change the path/create folder or else you want
First make folder lib new project source code then use relative address
in post-build event on visual studio go to properties in your project and add this:
copy "c:\pathtolibrary\bin\debug\namelibrary.dll" "$(SolutionDir)\bin\Debug\libs"
I am having problems getting my C# Solution to build "Fresh". If I clean the solution and build it again it will not build (I can do it a few times and it will build). It has an error about the azure project getting build before the worker and web projects that it is dependent on. Also about how most of the projects in the solution are looking for
WAT070 : The referenced assembly {...}/Worker.dll was not found.
Please make sure to build the role project that produces this assembly before building this Windows Azure Cloud Service Project.
{...}\VisualStudio\v12.0\Windows Azure Tools\2.2\Microsoft.WindowsAzure.targets 1252 5 AzureProjectName
Now if I build the projects in the order listed in the Project Dependencies -> Build Order everything works. Also, the web and work role are listed before Azure Project.
Solution is very simple.
You can set your project build order by right click on 'Project Solution' and select "Select Project Build Order" option.
For Example, I have a WpfFormApplicaiton1 and two class with title "ClassLibrary1" and "ClassLibrary2". By default Visual Studio sets it as follow:
My requirement is such as "ClassLibrary2" will be used by "ClassLibrary1" & "ClassLibrary1" will be used by "WpfFormApplication1". So, in order to fulfill this requirement I have to change the default project build order.
Go to Project Dependencies; Select the "ClassLibrary1" and set the "ClassLibrary2" as its dependency.
Similary, select the "WpfFormApplication1" and set the "ClassLibrary1" as its dependency.
Now, the desired project build order is set; confirmed by Project Build Order's options.
Solution is taken from my blog.
Your issue may be that the Dependencies are not defined. Even though the Build Order shows the order in which projects are built, if you do not define the dependencies for each one under Project Dependencies, msbuild will not know to wait for the dependencies build to complete before moving on.
To clarify: Unless you actually check the box that an item is a dependency, the projects in the build order list may build in parallel and not sequentially.
You can see under Tools->Options->Project and Solutions->Build and Runthat there is a default value for the number of parallel projects to build.
So to make the build process wait for dependencies to build make sure that all of the "Depends on" fields are checked for the projects needed under Project Dependencies -> Dependencies.
We had an issue where the project guids differed in case. Editing the project files solved the issue. We changed all Guids to uppercase
I just had this issue too. In my case the issue was that I had several project references within the solution. The other projects were using a different version of the framework to my Worker Role (4.5.1 vs 4.5).
When I changed all projects to use the same version of the framework the solution builds and runs successfully.
I had this issue. In my case, the solution's project build order, as determined by VS.Net, was not correct. Specifically, my web project was listed above three of its dependencies.
These three dependencies were listed under in the References node of the web project in the Solution Explorer. However, in the dialogue Project Dependencies, the web project did not depend on any project.
Also, I noticed that the web project had a small blue exclamation mark, with hoover-over message "The Web project '' requires SQL Server Express, which is not installed on this computer. ...". After fiddling with the web.config, based on ASP.NET Web Api: Project requires SQL Server Express and reloading the project, the exclamation disappeared and the project dependencies were correctly checked in the dialogue Project Dependencies and the build order reflected this correctly. However, when I reverted the changes to the web.config, as a test, the dependencies were not removed, so I am quite unsure what fixed my issues.
Anyway, in the dialogue Project Dependencies, you can manually check any project which was not automatically identified as a dependency.
Check to make sure there aren't any residual old files in your working folder. These can cause confusions with MSBuild. To avoid that, simply blow away all the old files in the path and get latest.
Using MS Visual Studio 2008, I created a C# library (let's call it main.dll) that relies on a second library (helper.dll). In the Debug version of main.dll, I set a reference to the debug version of helper.dll. But when I switch to build the Release version of main.dll, the output folder still includes the debug version of helper.dll. I do not see a way to select different versions of helper.dll for different build types. In C++, I could tell the linker what folder to get its files from, but I don't see a way to do that for C#.
The typical way of doing this is to have all of your projects in a single solution, and use project references between them. Then, when you build in Debug, all components will be built and referenced as debug - and likewise for Release.
Alternatively, you can use a single output folder for all your assemblies, reference each binary from there, and ensure that the build order is correct - so that your helper.dll is built to that folder before main.dll is built. This is more prone to failure, though, and requires a greater amount of manual maintenance.
When you switch from Debug to Release, Visual Studio switches from Debug to Release in the bin folder for the output.
Set the "Copy Always" property to true for main.dll. This will insure that it gets copied to the appropriate output folder, and is always referenced.
If the second library helper.dll is being built at the same time in the same solution, you can use a Project reference instead of referencing the .dll directly. Then, you can set up a solution-level configuration for Release mode, and build both projects in Release mode that way.
I have two solutions in my workspace, say A and B.
Solution A is an older project which I finished coding some time ago.
In solution B, I need to use some classes from Solution A. To do so, I add a reference to the dll of one of the projects in solution A.
The problem is when I try to debug. I want to be able to step into A's code as well. Visual studio is not able to load the code for these classes ("There is no source code available for the current location.") and I can only view the disassembly, which is not useful.
The only way I know to debug classes from solution A is by running solution B, detach all processes (in the Debug menu item) and attach the process from solution A.
However, this is very inconvenient and I can only debug A OR B at once.
Is there a way to allow stepping into the code of referenced dlls (for which I do have the source code)?
Solution: My mistake was that I thought that a project can only be part of a single solution. In fact, a project can be part of any number of solutions.
When you need to reference the old project, you should simply add the project to the solution. This is done by right clicking the new solution in the Solution Explorer > Add > Existing Project.
Then, you'll be able to add the project reference. As others wrote, you should probably completely avoid using dll references to your own code (or other code you might need to change and debug).
A very good reference to how solutions should be designed can be found in MSDN.
If you have a project reference, it should work immediately.
If it is a file (dll) reference, you need the debugging symbols (the "pdb" file) to be in the same folder as the dll. Check that your projects are generating debug symbols (project properties => Build => Advanced => Output / Debug Info = full); and if you have copied the dll, put the pdb with it.
You can also load symbols directly in the IDE if you don't want to copy any files, but it is more work.
The easiest option is to use project references!
I had the same issue. He is what I found:
1) make sure all projects are using the same Framework (this is crucial!)
2) in Tools/Options>Debugging>General make sure "Enable Just My Code (Managed Only) is NOT ticked
3) in Tools/Options>Debugging>Symbols clear any cached symbols, untick and delete all folder locations under the "Symbols file (.pdb) locations" listbox except the default "Microsoft Symbol Servers" but still untick it too. Also delete any static paths in the "Cache symbols in this directory" textbox. Click the "Empty Symbols Cache" button. Finally make sure the "Only specified modules" radio button is ticked.
4) in the Build/Configuration Manager menu for all projects make sure the configuration is in Debug mode.
Step 1: Go to Tools-->Option-->Debugging
Step 2: Uncheck Enable Just My Code
Step 3: Uncheck Require source file exactly match with original Version
Step 4: Uncheck Step over Properties and Operators
Step 5: Go to Project properties-->Debug
Step 6: Check Enable native code debugging
Another point to keep in mind, be sure the referenced dlls are not installed in the GAC. After testing, I installed my dlls into the GAC to do system level testing. Later, when I had to debug my code again, I couldn't step into the referenced assemblies until I deleted them from the GAC.
I had the *.pdb files in the same folder and used the options from Arindam, but it still didn't work. Turns out I needed to enable Enable native code debugging which can be found under Project properties > Debug.
When you want to set a breakpoint in source code of a referenced dll, first make sure that you have a pdb file available for it. Then you can just open the related source code file and set a breakpoint over there. The source file does not need to be part of your solution.
As explained in How can I set a breakpoint in referenced code in Visual Studio?
You can review your breakpoints through the breakpoints window, available via Debug -> Windows -> Breakpoints.
This approach has the benefit that you are not required to add an existing project to your solution just for debugging purposes as leaving it out has saved me a lot of build time. Evidently, building a solution with only one project in it is much faster than building a solution with lots of them.
Make sure your DLL is not registered in the GAC. Visual Studio will use the version in the GAC and it will probably have no debugging information.
I don't want to include an external class library project in some of my solutions, so I step into assemblies that I consume in a different way.
My solutions have a "Common Assemblies" directory that contains my own DLLs from other projects. The DLLs that I reference also have their accompanying PDB files for debugging.
In order to debug and set breakpoints, I set a breakpoint in the consuming application's source where I'm calling a method or constructor from the assembly and then step INTO (F11) the method/constructor call.
The debugger will load the assembly's source file in VS and new breakpoints inside of the assembly can be set at that point.
It's not straight forward but works if you don't want to include a new project reference and simply want to reference a shared assembly instead.
The most straigh forward way I found using VisualStudio 2019 to debug an external library to which you are referencing in NuGet, is by taking the following steps:
Tools > Options > Debugging > General > Untick 'Enable Just My Code'
Go to Assembly Explorer > Open from NuGet Packages Cache
Type the NuGet package name you want to debug in the search field & click 'OK'
From the Assembly Explorer, right-click on the assembly imported and select 'Generate
Pdb'
Select a custom path where you want to save the .PDB file and the framework you want
this to be generated for
Copy the .PDB file from the folder generated to your Debug folder and you can now set
breakpoints on this assembly's library code
The following solution worked for me. It involves copy pasting the .dll and .pdb files properly from project A to B:
https://stackoverflow.com/a/16546777/5351410
It must work. I used to debug a .exe file and a dll at the same time !
What I suggest is
1) Include the path of the dll in your B project,
2) Then compile in debug your A project
3) Control that the path points on the A dll and de pdb file....
4)After that you start in debug the B project and if all is ok, you will be able to debug in both projects !
Visual Studio 2022 added a new top-level node: External Sources to solution explorer, which you will find while in debug mode. You can look at all the loaded dlls from there. You can also look at the loaded modules from Debug -> Windows -> Modules in debug mode. From there, right click on your desired dll, and click open file location, and then copy the pdb file to that location. This should allow you to step into any methods of the external dll from the same visual studio window.
Reference: https://devblogs.microsoft.com/visualstudio/debugging-external-sources-with-visual-studio/