I have a Visual Studio 2010 solution that contains multiple projects. One of these projects is a library, which I have added a method to. Within visual studio I can navigate from the method call in my main project to the method in the library, but when I attempt to build/run the solution it gives me a "does not contain a definition for 'My_Method'". What am I doing wrong?
Seems you are not rebuilding the library project and/or you are referencing the output binary (dll) directly. To solve this you can do one of the following
Make sure you rebuild the library project, and reference the updated binary/dll
Reference the project directly if it's part of your solution, this way, every time you rebuild the dependent project, it will rebuild the library project. The drawback to this is, if you have too many projects, it will slow you (re)builds
It looks as if the library project isnt being rebuilt on each run, assuming that the project reference is correctly added (right click on references -> add reference -> select your library project)
You should make sure that your library is being rebuilt when you run.
To do so :
Right click on your Solution
Click on Configuration manager (approximative translation)
Make sure that the build is checked, if not, check if for the library project
Related
I am using VS2019 Community Edition and have created a C# Console App solution in one instance of VS2019 and a C# Shared Project in another.
I have added a class to the Shared Project and then want to reference this shared project in the other project, so I right-click the References and choose to Add reference, then choose Shared Projects. The resulting window shows an empty list. Am I doing something wrong?
Other questions I have found suggest that the wrong Shared Project was created, i.e. using the wrong language, but I have checked and mine are indeed both C# projects.
The other suggested methods were to add it to the project manually by editing the .csproj file, which didn't work either, or something to do with MS Build config which is more than I want to get involved with.
Is it me or VS2019?
UPDATE 1:
So I managed to kind of fudge it, buy adding the Shared Project to the same project as the console project, but storing it in a different folder and reusing the .sln solution file to load it as a solution in VS2019. Progress, but even though I can add it as a reference, it doesn't seem to know about the classes in the Shared Project, even with a using reference.
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 am using visual studio for this. I have test project which generates a dll and runs the different tests everytime I build the project. Now i want to write a console application which generates an exe that consumes the dll generated above. Can I do it using dllImport? If yes, please tell me how?
You just need to:
Add the test project in the same solution then,
add reference to project from your console application.
Now when you build the solution the library project will built first and its .dll will automatically be included in the bin directory of you console project. The advantage of doing this instead of referencing just the built .dll is you can modify and debug the source of your library project, e.g. step into it's methods.
However you can just do the second step and instead of adding a reference to your project browse to to the built .dll and add that as a reference.
You can either
Add the test project in the same solution then,
Add reference to project from your console application.
OR
Include a folder named Tests into your console app.
Add the test dll generated in it.
Add reference to project from your console application.
You can add reference :
In Solution Explorer, right-click the project node and click Add Reference.
In the Add Reference dialog box, select the tab indicating the type of component you want to reference.
Select the components you want to reference, and then click OK.
Please any one explain this. This Question helps to understand common things
Question:
What is the difference between when you 'add DLL reference from one project to another project via Browse Option and Add DLL reference from Solution project to another project and copy-paste from one project to another project'?
I have found an answer on google
Answer:
Adding a project reference adds a local project's DLL to the project that references it, and every time the solution compiles, the updated DLL for that project gets copied to the other project. So when you go through the build process, if you have 5 projects, each one rebuilds its DLL, and copies that DLL to its references.
But:
I don't know what the process is and the difference when we copy-paste from one project to another project?
When you do copy paste from One project to another, the dependent project add its reference of the file that you have paste in the project solution directory
When you do copy paste the dll of one project to the other project's directory and then Add its reference by browsing to that directory where you have pasted your dll. Then VS only add its reference and copy that dll to its bin folder and show you (allows you) all the method and properties that it contains.
If you do any change in your source project solution like adding or modifying methods then the updated dll of that project is not available in your dependent project solution.
So VS still points to the old dll file just because of the reference you added. So whenever you made any change in your source project solution, you have to add the reference of the updated dll to your dependent solution every time.
In Second Case: When you add reference of your source project into your dependent project solution, VS always take the most recent updated dll from your source project into your dependent project. So in this way you don't need to add reference every time you compile the code or debug.
When you just reference a DLL by browsing to it, VS would copy it to the output directory of the dependent project.
Suppose afterwards that DLL is updated - there is no guaranty that VS would retake that updated DLL, and copy it again to the output directory of the dependent project - which mean, that even after you fixed some bugs in the other project, those bug would persist in the dependent project (because it is still using the previous version of that DLL).
When you add reference to other project in the solution, VS would always take the most recent and updated DLL outputted from that project.
As the screenshot demonstrates, I have a project SampleApp that uses the namespaces EDAM and Thrift. I want to replicate the functionalities of SampleApp to another project.
Do I have to include the two projects (EDAM and Thrift) in my other project? Can I just copy the folders instead of including the actual project files? Can I just convert them to some sort of DLL or something?
You definitely should add references to the EDAM and Thrift projects from the SampleApp project.
To do so, follow these steps:
Right click the 'References' folder in the SampleApp project.
Select 'Add Reference...'
On the popup, go to the 'Solution' tab.
Select the EDAM and Thrift projects.
Under no circumstances should you just copy the files.
Don't copy the folders, just add references to the projects. Even if the projects are class libraries you don't want to copy the DLLs, instead you should add references, just in case your DLLs are updated:
How to: Add or Remove References in Visual Studio
If the "other" project is in the same Solution, you should be able to reference EDAM, Thrift and even SampleApp from that project much in the same way you set the references up for SampleApp.
If this "other" project will be in a new solution...I'd have to do a little research and testing.
Visual Studio project references are equivalent to referencing an assembly directly, but it has a great advantage: when you build a project, Visual Studio take cares of building its dependent projects too.
In addition, Visual Studio will prevent circular references.
There're many other pros, but it's a good summary.
Copy-pasting the code files isn't importing a namespace: this is duplicating code! And referencing the assemblies directly is a waste of time and features!