I have a Visual Studio solution (C#) which represents the core of our application. We build this and it comprises about 10 or so DLLs with corresponding PDBs.
I have several other VS solutions each of which is used for a customer of ours. These VS solutions use the core DLLs and add their own bits as required. The "core" has the main .exe so we do the following in customer specific solution
Post build step in the a project to copy the EXE/DLLs/PDBs into the $(TargetDir)
Set project debug settings to "Start External Program" pointing to the .exe
This all works, tho seems a bit clumsy.
My questions are:
When running via the customer specific solution, how can I
Have the code for the core project open automatically when I step into it
Be able to open a core file and set a breakpoint
I'm used to Java where you reference the compiled and source jars/directories from the Java IDE and that's pretty much it. How can do the same in visual studio (DLLs and PDBs)?
(I would prefer to avoid the GAC if possible because we sometimes have several local builds of the core around at the same time working on different projects)
Mike, if you open an "higher in stack" solution which references a core solution, you can open the source file of the core solution and put a breakpoint in it, then when you debug the current solution Visual Studio is smart enough to step into and trigger your breakpoint if the .pdb files are available in the bin folder.
TO automatically have the debugging control traverse into the core source files, make sure to refer the core dlls from locally build core solution and make sure that have access to it.
Another way is after having the core dlls refered, just open the CS file in which you want to put a break point and debug.
Related
I have a visual studio 2019 solution with a few projects that consist of mostly c# class libraries. This solution is never 'deployed' and is always run locally by anyone who uses it. Part of what we do for one of our test projects to work is put certain dll's we use into our bin/Debug folder. One of these is Newtonsoft.Json.dll for example. We have a specific version of that dll that we're required to use.
This is something that is usually done once, the first time we run a test in that project. This all works fine. However, whenever there is a code change and the project builds, for whatever reason all the files that are in "C:\Program Files\IIS\Microsoft Web Deploy V3" are copied into our projects bin/Debug directory and overwriting any of the same files already there (Newtonsoft.Json.dll being one of them), and it's a different version which then breaks our projects dependency on that version of the dll. It's worth nothing there are also a bunch of random other files/folders in that Web Deploy directory that get copied over that our project does not need to be there.
I've checked all build events, and searched the entire solution to see if we reference that directory at all which we don't. I've tried googling similar issues, but almost all of what I can find is related to how to use Microsoft Web Deploy (which as far as I can tell we're not, and intentionally as I mentioned we don't deploy any of this code).
If anyone has any insight on this, it would be greatly appreciated!
Thanks,
Andy
I started learning c# a couple days ago and want to send my first program to my friend but as a standalone exe file that can be shared through google drive.
I've found several solutions but I coudln't understand any of them. Is there a simple solution to compile an exe file or a standalone app in visual studio 2019 that would just work when you open it
One annoying thing with .NET Core is that when you build it in Visual Studio it makes lots of separate files, which is annoying for portability.
A fix to this is to right-click on your project in Solution Explorer and click Publish. Select Folder Profile, give it a name and save it.
After that, you will need to edit the target runtime option, and set it to win-x86. After that, you should see a dropdown box at the bottom of the dialog, expand it and check 'Produce a single file'.
Then you can hit Publish and it should produce a single file.
NOTE: This does not work in .NET Framework, only .NET Core.
All you gotta do is simply build the project within Visual Studio, once that's done. Go to your projects folder and go into bin/Release (or Debug if you've selected debug build)/myprogram.exe. It should make a standalone .exe file!
Maybe this could also help you.
Official Documentation: Compiling Building in Visual Studio
I have a big solution with 30 projects of which 2 are web projects (MVC and WebAPI) with a bunch of background class library projects.
I have visual studio set up to host the web projects in IIS.
If I do a clean build, followed by a full build of the entire solution, then accessing both projects via a browser works fine. (they are in diff folders and hosted on diff 'domains' in iis)
If I make NO code changes, simply rebuild one of the 2 web projects, the OTHER one stops working.
To be clear, rebuilding the WebAPI project causes the MVC project to have errors. And vice versa.
The error I get is saying that System.Web.Http.Formatter is not found. The detail says that the located assembly version is different from the reference version. Checking the bin folder shows that that is not the case.
Make sure that all the solution's resources are up to date. If you use Nuget, update all packages in all projects (back up first!). It sounds like you have a version mismatch, where functionality is missing in DLLs copied to the output directory for the solution. It may involve changing some entries in the Web.config of each project, but without access to the code, it's hard to know for sure.
Report back once you've updated every library, and made sure the versions match across all projects in the solution.
In addition to Apache's and Steve's suggestions, I'd also recommend deleting the files in your Temporary ASP.NET Files directory. If you're curious here's a good write-up of what the contents of that folder are for.
I have a visual studio 2010 web project that when I publish it in debug mode the application works fine and is the latest build.
However, when I try to click the play button/debug mode (in the same build configuration as what I published in) the assembly version is older than the most current one. As mentioned, this is a asp.net application using a c# class library as a reference (also in the solution) and I am debugging using Visual Studio's built-in web server.
I've tried everything I could think of at first in all different combinations as follows:
Clean solution
Clean each individual project
Build solution
Build each individual project
Rebuild solution
Rebuild each individual project
I tried to use a different browser and cleaned my cache as well.
Has this happened to anyone? How can I correct this issue?
It is most likely not set to build. To test this, try build then debug and see if things work. If so, then it is definitely not set to build.
To solve this, open up the Solution Properties. Go to Configuration Properties >> Configuration. Then run down to the project in question and check the Build checkbox. You will then be able to debug again.
This one bit me when a coworker decided the build of the UI was taking too long for his testing and removed it from the build. After discovering the issue, I had him create a separate solution to test in isolation. Yes, multiple solutions can contain the same project(s).
did you try deleting your bin and obj folders and removing your assemblies from the GAC? I would guess that THIS is the problem.
Don't forget to clean your Temporary ASP.Net (c:\WINDOWS\Microsoft.NET\Framework[version]\Temporary ASP.NET Files) files.
After that, do a rebuild and try.
Also, for local development, if you can, then do not GAC assemblies. GAC them while deploying to integration environment. THis will help speed up development a bit.
I am building an application which is based on a sample application,
written in C# on .NET 2, and is built on VS2008. This application is mostly a wrapper for a COM application.
However I compile it in .NET 3.5.
The sample application came with the following files in it's bin\debug:
appName.vshost.exe
appName.vshost.exe.manifest
I noticed that I can delete the files and VS re-builds vshost.exe, and the vshost.manifest file appears with modification date the same as the deleted file as if VS has copied in from somewhere.
My question is, should I put this files in my SVN code repository?
Those two files you list implement the Visual Studio "hosting process". It is a hosted version of the CLR, designed to improve the debugging experience. It takes care of some security issues, the most visible side-effect is that it redirects output written with Console.WriteLine() in a GUI app to the Output window.
These files are not part of your project and do not get deleted when you use Build + Clean. In fact, you cannot delete the .exe file, it is always running while you've got the project opened in Visual Studio. You can disable the hosting process feature with Project + Properties, Debug, scroll down, "Enable the Visual Studio Hosting process" tick. There's no compelling reason to do so.
There's no need to check these in, Visual Studio re-generates them when you check-in a project and load it in VS. In general, you never need to check anything in from the bin subdirectory, its content is always re-created by building your project.
Everything in the debug (or release) folder is generated. Everything that's generated shouldn't be checked in.
When in doubt, just make a fresh checkout to some other folder (or even machine), and try to build from that. If something is missing, this will find it.
I do not think you should. They are for VS use only.
Here are the files I ignore when creating C# projects. You really only want to store the source code in the repository and not the outputs. Similarly you probably do not want to store the user based information that goes along with VS solutions.
*.csproj.user
*.suo
bin (folder)
obj (folder)