My apologies for this very basic question that has assuredly been asked and answered before, also for my very dated terminology. I searched for an answer, but failed to find anything helpful. I am using the latest update of VS 2017 Community, and I'm trying to manually add what I used to call a "function library" to a project, which sits under a "solution".
The project is simply a C++ or C# console application. What I have is a .h (header) file, a .lib (static library) file, and a .dll (dynamic library) file. I intend to make "function calls" to this library. I'm aware that I need to have my dll in the debug folder where the executable resides, but I'm not sure how to "add dependencies" in VS 2017. I know how to manage and install NuGet packages, but these files aren't a handy-dandy NuGet package.
I hope to get advice on doing this the right (VS 2017) way.
What I do in a situation like this is to create a folder, I use C:\Etc\SDKs\<name_of_library> and then within that folder create an include subfolder, and a lib subfolder. Note that the top level folder choice is completely arbitrary, place it where it makes the most sense to you.
In the C/C++ section of project properties on the General tab, or the corresponding section for C# projects, there's an entry for Additional include directories. Add the path to your newly created include folder there. That'll let you include the header file and have it work right.
In the Linker section of project properties, also on its General tab, there's a corresponding entry for Additional library directories. Add the path to your lib folder there. On the next tab down: Input there's an entry for Additional Dependencies. Add the actual name of the library file there.
Those steps should allow your project to be built using the .h, .lib and .dll files you have.
-- Edit to address comments --
The .lib file does go in the ...\lib folder, and the .h file in the ...\include, that's correct. However, you had the location of the .dll correct in your original question. That needs to be somewhere on the search path that the executable will find, so the easiest place is the same folder as the executable.
General tab is a poor choice of words on my part. General section might have been better here. When looking at the project properties, the left most pane is a tree view of the various property sections. With everything closed up, except the very top item open, you'll see
Configuration Properties
General
Debugging
VC Directories
> C/C++
> Linker
...
If you then double click on C/C++ it'll open up, and show the sections specific to the C/C++ compiler:
Configuration Properties
General
Debugging
VC Directories
V C/C++
General <<<<<
Optimization
Preprocessor
...
> Linker
...
If you click on the word `General that I've highlighted, that'll get you to the General section / tab I was talking about.
Likewise, double clicking the word Linker will open up that section, and under that you'll find the Linker General and Input sections.
Let me know if this still isn't clear, and I'll try to clarify.
Related
We have a scenario like this:
We have ~100 solutions containing 10 projects each.
Each solution copies its artefacts (i.e. its 10 dlls) to a shared single folder like C:\code/assemblies.
If I develop something for feature X, I'll open up SolutionX.
The source for all solutions/projects is local in a single Monorepo C:\code.
During debugging, when the method/class/whatever is implemented in project Y, it opens the corresponding file (which is nice). So there must be information available how to get to the source.
But when developing, I cannot navigate to the implementation e.g. by using F12 ("go to definition") but just get the signatures gathered from meta data. I'd like to have the same experience like during debugging.
So right now I open up a Visual Studio Code, open the folder containing the sources and do a "search in files".
Any better ideas?
N.b. Resharper is not an allowed option. Also doesn't play nice with Postsharp.
N.b. I don't know if it is important but all except one solution start an external program (the shell), since all except one solution contain only dlls.
I have done similar in Old project.
You can use Symbol with Visual Studio 2019. Simple steps can be:
A. Generate Symbols for projects :
In Solution Explorer, select the project.
Select the Properties icon (or press Alt+Enter).
In the side pane, choose Build.
In the Configuration list, choose Debug or Release.
Select the Advanced button.
In the Debugging information list, choose Full, Pdb-only, or Portable.
Refer for more information:
Set debug and release configurations in Visual Studio
Publish symbols for debugging
B. Use Symbol in Visual Studio:
In Visual Studio, open Tools > Options > Debugging > Symbols (or Debug > Options > Symbols).
Under Symbol file (.pdb) locations,
To use the Microsoft Symbol Servers or NuGet.org Symbol Server, select the checkbox.
To add a new symbol server location,
Select the + symbol in the toolbar.
Type the URL (http), network share, or local path of the symbol server or symbol location in the text field. Statement completion helps you find the correct format.
Tools - Options - Debugging - Symbols page
For more Details refer:
Configure symbol locations and loading options
I think you should analyze project dependencies (for example with https://www.ndepend.com/docs/visual-studio-dependency-graph ) and cluster your projects in less Solutions
Edit : I am editing this answer based on your comment. I think you are looking for two use cases
Peek into the source code of referenced binaries
Navigate to the source and then edit them in place
To achieve option (1)
In Visual Studio 2019, use the built in decompiler to help you with navigating to code outside of the solution. This is an experimental feature as of May 2020. By default this is disabled and you should enable it. Once enabled the F12 navigation will decompile and allow you to peek into the source code.
On the other side, the more you relax the compilation the better the decompilation. Meaning, you can turn off optimisations (if any). This doesn't have to do anything with symbol generation options.
If you are using visual studio 2017 (or) less, the same can be achieved by Telerik Just Decompile plugin (free). Check the feature View decompiled code in tabs
To Achieve option (2) :
You should reference source files rather than binaries, because you won't get the natural in-place edit with referencing binaries. There are always going to be caveats irrespective of the solution you choose. Referencing source can be done using the "Add as link" feature in Visual studio, where the source code belong to one solution and can be referenced as link (something like windows shortcuts) in all the other solutions. (https://andrewlock.net/including-linked-files-from-outside-the-project-directory-in-asp-net-core/). If you are referencing source, you need to remove the binary references.
And you also have to decide from an architectural standpoint on how this changes the way people develop and commit code. The point of referencing binaries is to make sure they are not edited for convenience, but that depends on the nature of the development team purely.
Conclusion
From a best practices standpoint, you either have to reference binaries and don't allow them to be edited (or) you allow source references and edit in place. But that depends purely on what you want to achieve.
My understanding (which may well be faulty) is that it is easy to set the OriginalFilename property for a C++ DLL or EXE by including a VERSIONINFO resource file in the Visual Studio build.
But I can't find any way of setting OriginalFilename for a C# build. It is apparently always set to the name of the output file being built.
I'd really like to be able to specify this if possible. Any ideas? Thanks.
OK, no answers, and now I've found a workaround.
This article here at StackOverflow was very helpful:
How do I set the version information for an existing .exe, .dll?
Which led me to this resource manipulation project written in C#:
http://resourcelib.codeplex.com/
So what I'm going to do is to modify the DLLs after they've been built.
Edit (March 2015): This is an old posting, but I can see there is still some interest in it. The "ResourceLib C# File Resource Management Library" open source project has moved since four years ago, and is now here: https://github.com/dblock/resourcelib
Yes it is possible to set it,
-> right-click on the project or assembly name in visual studio -> select properties -> select Application tab -> change the assembly name as you want.
Please refer the link to view property window, in which assembly name option is there
After changing the name compile the project,(to verify the change) right click your compiled DLL file and select properties and click on 'Details' tab, in which you can see the 'original filename' is now changed.
Sadly, no.
You can read what it is with System.Diagnostics.FileVersionInfo.OriginalFilename, but the value is filled by the Project / Output Filename not from any Assembly Attribute.
Running your patch program to change it after a build runs the risk of breaking any digital signature applied during the build. You may need to build without signing, patch the attributes, then sign it in a separate step.
My situation:
I have a solution A with hundreds of projects,
Some of projects are class libraries and are referenced from other projects.
Now I want to create a new solution B which will consist of subset of projects of solution A. I start by adding the first pre-existing project into this new solution B. This project is referencing couple of class libraries from solution A. Therefore it is logical that these libraries cannot be found and I cannot build. Of course I could add all the referenced projects manually into the new solution B but that would take quite a long time, considering the total amount of projects that I need to add.
Is there some built in Visual Studio feature that can take care of this on my behalf? I.e. I will be offered an opportunity to import all the referenced projects at once and the B.sln file will be updated automatically.
I also have a ReSharper extension but I couldn't find such feature in there as well.
EDIT:
Some more detail on what I am trying to achieve. A.sln has lots of application projects and literally hundreds of class libraries. I want to create a new B.sln for one particular application project from A.sln and only add the class libraries that it is referencing, directly or indirectly... But the dependencies can go up to 15 levels deep so manually removing projects from original A.sln to create B.sln is really not suitable for me as I would have to carefully consider each one of the projects that I would be manually removing from the original sln file, subsequently reviewing the csproj files to find whether the application I am interested in does not indirectly depends on them via one of its direct references.
Copy paste your current solution file and start with it. Open it in new Visual Studio Instance. Remove your projects one by one. Instead of adding new projects, removing unnecessary ones will be more easy for you. As far as I know there is no such feature in Visual Studio as you want.
Removing will be more easy since projects are already there. Do not use Visual Studio to remove project but open sln file in suitable programmers notepad. Your projects are added to sln file as below lines.
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Example.Integration.App1", "..\Example.Integration\Example.Integration.App1\Example.Integration.App1.csproj", "{E3977144-AFBA-451D-894C-1F89AA008041}"
EndProject
Removing such lines will be more easy if your projects has naming convention.
The best way to port references from an existing project that I've found is to generate a template for that project.
On the File menu, click Export Template. The Export Template wizard opens.
Choose project template and move through the wizard
Click Finish. Your project is exported into a .zip file and placed in the specified output location, and, if selected, imported into Visual Studio.
Now, when you setup a new project for solution B. You'll be able to choose the project template from A and all the file structure/references are preserved.
Ref: http://msdn.microsoft.com/en-us/library/vstudio/xkh1wxd8%28v=vs.100%29.aspx
I have two very long and detailed .csproj files.
I want to combine them into one.
I used text comparer but the items are not in the same order
and it's hard to isolate differences.
How would you recommend to combine them?
(they have compile, include, post build and after build events)
edit:
I want to merge 2 unrelated projects with some common dependencies
Copy the files from project 1 into the project 2 folder. Then turn on "Show all files" so you can see the files that aren't in the project. Then right-click each file and choose "Include in project".
I would probably do most of this in Visual Studio. You can either drag the files you need from one project to the other, or you can copy all the files from one project folder to the other in the file system and turn on "show all files" in the solution explorer to show which need to be added. You will then need to align the namespaces. The Class View window can help identify types which do not fall inside the right namespace. A refactoring tool like Resharper can also help fix up the namespaces.
If you have explicit pre or post build events in each project, I would use the VS GUI to show these and manually combine. If you have custom build targets/tasks in the files, I would isolate these in a good text/XML editor and manually union them as required.
The other thing you will have to do is to add references to the final project which it did not originally require but were required by the other project. It should be quite quick to identify which references need to be added, by attempting compilation and inspecting any errors.
The java build tool "maven" has a standard directory layout for projects. What is the equivalent type of directory layout for a C# project? I'm just learning C# and .NET and it seems that the IDE just dumps everything into one directory, heh. Does C#/.NET follow a convention for the directory structure?
EDIT: This would be for a desktop application (windows forms or wpf). I'm looking at one of these two, but I don't know enough yet to really know which one. Ultimately I would like to learn both.
In C# directory layout should be strictly related to the namespaces you have. Each directory creates subnamespace. Here you may find instructions how to name namespaces properly.
If you use FxCop, it will inform you if your directory (namespace) layout is OK. The main rule is that there shouldn't be namespaces with a few classes/interfaces (FxCop suggests merging two namespaces into one in such a situation).
I think that's all I can say without knowing of some special project type (Uwe mentioned some of them in his comment) you have in mind.
Usually you get the following structure in your project :
/bin/Debug (after a DEBUG build)
/bin/Release (after a Release build)
/obj/Debug
/obj/Release
/Properties (contains AssemblyInfo.cs + Resource files when added via the assembly's properties)
/ServiceReferences (contains service references if any are present in your assembly)
In addition to the above, any solution folders you create (via r-click solution explorer -> add new / folder) will be present in your project's folder.
Does this help?