For example, I have two projects let's say project A and project B. I have the source code of project A and project B.
Then in my project A, there are some .a files made by project B. Project A use those .a files to compile and run.
The question is, when I run project A, I want to debug the codes in those .a file. Is it possible? If possible, how can I do it?
I'm using Visual Studio for Mac.
Note: Project A is written in C# and Project B is written in C++.
It‘s a Xamarin project.
If you have no source code of project B, then you can only debug in assembly mode.
If you do have source code of project B, make sure .a files reserving debug info(like dwarf) and use lldb source-map technique to perform mapping.
But, if you have .a file's source, why not just build with project B source.
You need to attach with Visual studio to the running process. Attaching to process with Visual Studio is done with Alt + Ctrl + P on windows.
In case the code you wish to debug is run at startup of your app, place your breakpoints and add a 30 seconds sleep (before any of your breakpoints) so you have time to attach.
When picking the process, make sure to tick the right code types to debug by clicking Select...
If you have access to source code for both projects, I would recommend to create a solution with both projects, as you may be able to use different language projects on same solution (please check this, as an example: https://social.msdn.microsoft.com/Forums/en-US/737e2bf3-86ab-49aa-bafa-b3a3d05ce826/mixed-languages-in-visual-studio?forum=csharpgeneral).
To debug C++ code inside the C# project, check options for your current Visual Studio version, as suggested in this post:
Debug c++ dll in C#
Set project A (C#) as start project, and, if references are correct, you should be able to debug .a files referenced from project B.
You can build both Debug and Release into separate preset directories in any IDE. This is a good practice for all builds - using Configuration -> Release and Debug. You may name the libraries as libname_d.lib and libname.a so they do not get mixed up.
Then you can link to the appropriate library (libname_d.a) while debugging. Its a matter of choice - some may not recommend linking multiple projects into the same Solution (or Workspace), since each separate library will have a separate set of tests. These are difficult to manage in a single project.
Ideally, each library can be coded and tested separately and built into Release and Debug. This way functionality can be isolated and object-based design can be followed.
Its also important to understand the difference between .a (Linux, Mac) and .lib (Windows) - see here - What's the difference between .lib and .a files?
Related
Basically I want to block developers from building one of the projects in a solution that only the build server can/should build.
Alternatively, Developers would have a solution with projects A, B, C but not D. However, The build server would add project D to the solution. Then build the solution with projects A,B,C, & D.
Can this be done through code and/or configuration?
Thanks
Not really - if code is available it can be built by developers. One can create project file from source and build it to be able to debug the code for example.
You can use NuGet to import pre-built assemblies - this way you discourage building such code locally.
Note: make sure you understand reasons why one would want to build that code locally - debugging is very common reason and degrading debugging experience will slow your team down.
Well one of possible solution would be creating different build configurations. Each build configuration would include projects needed to run properly.
Simplified example:
Developers could use default Debug configuration to build projects A, B and C (D must be excluded from this configuration) to run application locally.
Production configuration would have all projects (A, B, C and D) included, and your continuous integration system would use that configuration to build your solution.
Keep in mind what others said, you won't be able to protect project D from manual or accidental builds, as long as it stays inside same solution.
I want to obfuscate a single .dll file (to hide constants). When I confuse .dll compiled as release for any processor AND application is started from .exe - everything works fine.
Unfortunately this .dll is meant to be a "key" for some things in our database that we want to give to someone else to use. But I don't want them to be able to recover this source code in like 2-3 clicks by DotPeek or any other reverse engineering tool for C#. They are still testing their things, so they start their app from Visual Studio.
When I add non-obfuscated .dll to my test project as reference - everything is fine. But when I add already obfuscated .dll as reference I get 'FatalExecutionEngineError'. And that's unfortunately the whole point - I want them to have this .dll for usage and testing purposes, but after obfuscation it may not be possible for them to use it from Visual Studio.
Am I doing something wrong or should I just use a different obfuscation tool?
In my solution we have projects both in c#, that controls some GUI and networking work, and c++, that manages some hardware interactions. In my c# project I have the proper PInvokes and am able to use the c++ output dll with no issue but in order to do it, I have to manually copy the output dll to the build directory or create a build script that manages the copy.
My issue with this method is that the solution, in reality, has many many projects, something like 150 at the moment, covering c++, c, c#, and vb.net. We create and delete projects all the time and managing the copy scripts is becoming a major pain. Especially since not all of the projects rely on each other and we have like 20 different build configurations.
Is it possible to simply have the c# project reference the c++ project and automatically copy the project output the same way it does with other managed projects without using post build scripts?
Well, the way I do it and have always done it is by obviously using Visual Studio, and assuming this C++ projects are VS projects you can easily create a VS Solution containing multiple projects that you can organize with "Solution Folders". The organization of your projects inside the solution is really up to how you want to organize it. It resembles a file system with nested folders. Needless to say that you can host projects in different languages such as C++, C#, VB...I'm not too sure if you can include a C project or not, that's out of my expertise.
See a screenshot below of a solution I created to demonstrate this...
Notice that "Business" has a nested solution folder (Utils) which contains a C++ project (ERM.CPPLibraries) and a VB project (ERM.VBLibraries). Then if you reference projects within the solution (Right click -> Add Reference), you will not need to copy the output assemblies everytime you compile your solution (or project(s)) VS is smart enough to resolve all dependencies, resolve them and update them.
Hope it gives you an idea
Edit based on comment
In simple words...No, it's not possible to reference a unmanaged project from a managed project in a VS solution. You can reference DLLs but not projects itself
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 already come across the Stack Overflow question "Is there a way to generate a DLL file from Visual Studio Express without explicitly creating a DLL project?", but it does not directly answer my query, so I'm raising it here.
The problem I am facing while trying to make the DLL is that I can't find any option under Build named build class file.
I have changed the project property to class file (shown below)
This is how it is:
And here is how my build option is getting displayed:
Also when I am using the command-line option the dll file is getting generated but it is not getting the properties I'm setting in the application.
I am new with Visual Studio so a litte bit confused about this part.
The "Build Solution" option in your second screenshot is the thing you need to click to produce your dll, alternatively you can right click on your project in the Solution Explorer and click "Build":
(If you only have one project in your solution then these two will both do exactly the same thing)
The output dll will normally be placed in the bin\Debug or bin\Release directory depending on whether you are in Release or Debug configuration, check the "Build" tab of the project properties for the exact path.
The reason why you aren't seeing a "Build class file" option is because this is what the "Build project" menu item does - it will produce a class library if the project output type is "Class Library", a windows executable if the project output type is "Windows Application" etc...
You're not trying to build a class file - you're trying to build a class library.
And you just build the solution - that will build each of the projects in your solution, including your LicenseCheckLibrary project is just a class library project.
It looks like you're basically there - look in the bin\Debug or bin\Release folders under LicenseCheckLibrary, and you'll find the DLL.
Why would you want to avoid building a DLL file in the first place? Are you developing an EXE file in order to test the logic and then conver it to DLL once it is working fine? If yes, why not create two projects: Windows Console and Class Library. Inside Class Library implement the licensing logic and use Windows COnsole to test the logic. When you say you are new with Visual Studio, what exactly do you mean? You never used it before or you are new to .NET Framework programming? .NET Framework has certain classes for developing licenses. Also, there were quetions here on stackoverflow regarding the licensing. Find some of them instead of reinventing the wheel.
Have a look at this article http://www.developer.com/net/net/article.php/3074001
Create a new class library project
Create classes and code
compile Project
Dll Created
Create a new project
Click on Add Reference
Navigate to the class library folder
Go into the debug folder or whatever and include
Remember you will prob have to include the namespace. in the new
project.