I have a windows service, which when built, includes the PDB files in the output.
I have a Service Installer project, that generates an MSI for installing the service.
I'd like to make it also include PDB files in the output (at least for a particular build configuration, but for all is fine too).
For other project types, you can generally go to Properties and change the settings, however there isn't much on the properties on the ServiceInstaller.
edit:
After some fiddling I've found that I can add the debug symbol output of a project, if I apply it to the service, it seems to include the PDB of the service, which is great. However I was expecting it to include all the pdbs, for all the referenced projects too. Since the service is quite slim and calls into other libraries... Will keep at it...
In the end, I told it to add debug symbols from every project individually by adding them one by one.
This is not ideal, because if projects are added the person adding them will need to remember to add their output to this, whereas if I could get it to just do *.pdb, the target service automatically includes pdb files for all of its referenced projects so that wouldn't be necessary.
However it has done the job for now. I will not mark this answer as accepted in case someone knows of a better way.
Related
I have multiple projects (lets call one MyLibrary) in Visual Studio that contains a lot of nifty functions and classes I use in my other projects. I add a reference to MyLibrary.dll directly and not the project itself.
However, I now need to breakpoint my way through something in MyLibrary while I run one of my other projects. How can I debug my dll the way I've set up my projects? I know for a fact I've done it earlier with these projects, but since I didn't do anything special, I don't know what's missing.
I've turned off Just-my-code and followed some tips like that, but I haven't gotten into .pdb's yet. If I need one to debug another DLL, I would appreciate some information on how to export that from MyLibrary.
While debugging, check in Debug/Modules, if your dll symbols are loaded. If not, let them load. You may be asked to set the folder with pdb files. Pdb contains the symbol used for debugging. It has to be the same version as dll file you are using in your projects. After that you will be able to debug the library.
You might need to go to the properties of a DLL, and ensure that Copy Local is set to True. Otherwise, Modules won't be able to find the .pdb for your reference
If that doesn't help you can try to rebuild your external library using debug mode, then copy manually both .dll and the .pdb file to the bin of your app.
I have files in ...bin/release where is my windows form application, I have used EEPlus library as well. What the files do I need to send to client to have application work correctly?
My files:
name.exe
name.exe.config
name.pdb
name.vshost.exe
name.vshost.exe.config
name.vshost.exe.manifest
EEPlus.dll
EEPlus.xml
I know that first two are mandatory, but what about all rest?
thanks in advance
name.exe //necessary, it is your main executable
name.exe.config //necessary, it is your application config file
name.pdb //not necessary, it contains code and debug symbols configuration of your assembly, but let it be there, it is useful when users encounter a bug or crash
name.vshost.exe //not necessary, it is the hosting process of visual studio for debugging purposes
name.vshost.exe.config //not necessary, config file of name.vshost.exe
name.vshost.exe.manifest //not necessary, manifest of name.vshost.exe
EEPlus.dll //necessary, it is one of your application dependencies
EEPlus.xml //not necessary, contains some information for EEPlus.dll
reference for xml, reference for vshost, reference for pdb
All except *.pdb and *vshost*.
Really you should look at the REFERENCES of your project.
Generically all the assemblies that don't make part of the NET Framework need to be redistributed.
In this case, it seems that you need to distribute EEPlus.dll only.
The other files are there just as a byproduct of the compilation.
Of course, you should also consider that a thirdy party library could need other files, but this should be explained in their documentation under the redistrubute page.
You could try this:
Delete all files except the name.exe, name.exe.config and EEPlus.DLL, then run your app outside VS directly in the BIN\RELEASE folder. However I recommend to have a clean virtual machine where you could test your app and be sure to not forget anything.
Always
name.exe
name.exe.config
Dependency dlls
Interop dlls
First we check this mandatory files before giving to client, because at client, when running application that will be crashed without displaying any errors...
I have a c# ClickOnce application that I need to be able to publish multiple times for OEM purposes.
The way I understand it now is that publish settings are located in the .csproj file.
However, this is inconvenient in the case where I want to publish multiple versions.
for example, Company A needs totally different icons, start menu location, product name etc. from Company B, but the assemblies need not be renamed.
Here are a couple approaches/questions that I can think of to solve this issue...
1.Is there a way to create a separate publish settings file to use during build time?
2.Can I edit specific publish settings (like Start Menu location, etc) at build time with MSBuild.exe? I think this would be ideal...
e.g.
MSBuild.exe project.sln /target:Publish /property:edit-project-publish-settings-here
3.Maybe create a 2nd .csproj file? (Would prefer not to do this...)
Please share your thoughts as to the best approach, or any other clever ways to make this happen. Thanks!
I wish I could give you some brilliant solution, but personally I would probably go with option 3.
I mean, its pretty simple, the changes should be pretty static and it will be difficult(ish) to totally screw it up and deploy the wrong changes to the wrong company.
If you copy the .csproj in your project folder, it will reference all of the same source files and you can just change the executable name. Create another VS solution and you can reference the copied .csproj and get rid of your first one so that you can publish two separate versions.
This isn't ideal for ClickOnce however.
If you use a Singleton object that specifies the "mode" (Company A, B, C, etc.) you can easily store that in the app.config (or another xml file). Then just re-publish your ClickOnce Application but copy the correct version of your configuration file in so it gets shipped with the build. This way, you don't need any additional csprojects Just include all of your icons and set them at run-time on App Start based on your Singleton object.
I found that you are able to edit certain properties using MSBuild.exe like this
MSBuild Solution.sln /target:publish /property:ProductName=ProductA\;Publisher=CompanyA\;ApplicationIcon=companyA.ico
I found another useful post on modifying.csproj files programatically with .NET code. (This would only be needed if you're modifying things that are deeper than just the project properties specified in the ClickOnce documentation below)
The MSBuild documentation here was also useful -- especially under Publishing Properties
We have a moderately sized solution, with about 20 projects. In one of them I have my business entities. On compiling any project, visual studio waits and hangs about one and a half minutes on this BusinessEntities project.
I tried our solution in SharpDevelop and it compiles our complete solution, in 18 seconds. Similar timing with MSBuild.
My guess is that VS is trying to find out if the project needs a compile, but this process is about 15 times slower than actually performing the compile!!
I can't switch to the great sharpdevelop, it lacks some small, but essential requirements for our debugging scenarios.
Can I prevent VS from checking this project, And have it compile the projects without such a check, just like sharpdevelop?
I already know about unchecking projects in configuration management to prevent building some projects, but my developers will forget they need to compile this project after updating to latest sources and they face problems that seem strange to them.
Edit: Interesting results of an investigation: The delay happens to one of the projects only. In configuration manager I unchecked all projects, then compiled each of them individually. All projects compile in a few seconds!! The point is this: if that special project is built directly, compiles in a few seconds, if it is being built (or skipped, because it is up-to-date) as a result of building another project that depends on it, VS hangs for about a minute and half, and then decides to compile it (or skip it). My conclusion: Visual studio is checking to know if any files are changed, but for some reasons, for this special project it is extremely inefficient!!
I'd go to Tools -> Options -> Projects and Solutions -> Build and Run and then change the "MSBuild project build [output|build log] verbosity" to Diagnostic. At that level it will include timings which should help you track down the issue.
We had the same problem with an ASP.NET MVC web project running in Visual Studio 2013. We build the project and nothing happens for about a minute or so and then the output window shows that we are compiling.
Here's what fixed it... open the .csproj file in a text editor and set MvcBuildViews to false:
<MvcBuildViews>false</MvcBuildViews>
I had to use sysinternals process monitor to figure this out but it's clearly the cause for my situation. The site compiles in less than 5 seconds now and previously took over a minute. During that minute the Asp.net compilation process was putting files and directories into the Temporary Asp.net Files folder.
Warning: If you set this, you'll no longer precompile your views so you will lose the ability to see syntax errors in your views at build time.
There is the possibility that you are suffering from VS inspecting other freshly built assemblies for the benefit of the currently compiling project.
When an assembly is built, VS will inspect the references of the target assembly, which if they are feshly built or new versions, may include actually loading them in a .Net domain, which bears all the burdens of loading an assembly as though you were going to run it. The build can get progressively slower as it rebuilds more and more projects. When one assembly becomes newer the others do a lot more work. This is one possible explanation for why building by itself, versus already built, versus building clean, all have seemingly relevantly differing results. Its really tht the others changed and not about the one being compiled.
VS will 'mark down' the last 'internal' build number of the referenced assembly and look to see if the referenced assembly actually changed as it rolls through its build process. If its not differnt, a ton of work gets skipped. And yes, there are internal assembly build numbers that you dont control. This is probalby not in any way due to the actual c# compiler or its work or anything post-compile, but pre-compile steps necessary for the most general cases.
There are several reference oriented settings you can play with, and depending on your dev, test, or deployments needs, the functional differences may be irrelevant, however may profoundly impact how VS behaves and how long it takes during build.
Go to the references of one of the projects in Solution Explorer:
1) click on a reference
2) open the properties pane if its not (not the Property Pages or the Property Manager)
3) look at 'Copy Local', 'Embed Interop Types', 'Reference Output Assembly'; those may be very applicable and probably something good to know about regardless. I strongly suggest looking up what they do on MSDN. 'Reference Output Assembly' may or may not show in the list.
4) unload the project, and edit the .proj file in VS as text. look for the assembly reference in the XML and look for 'Private'. This means whether the assembly referenced is to be treated as though its going to be a private assembly from the referencing assemblies perspective, vs a shared one. Which is sort of a wordy way of saying, will that assembly be deployed as a unit with the other assemblies together. This is very important toward unburdening things. Background: http://msdn.microsoft.com/en-us/magazine/cc164080.aspx
So the basic idea here is that you want to configure all of these to be the least expensive, both during build and after deployment. If you are building them together, then for example you probably really don't need 'Copy Local'. Id hate to say more about how you should configure them without knowing more about your needs, but its a very fine thing to go read a few good paragraphs about each. This gets very tricky however, because you also influence whether VS will use the the stale old one when resolving before the referenced one is rebuilt. As a further example explaiing that its good to go read about these, Copy Local can use the local copy, even though its stale, so having this set can be double bad. Just remember the goal at the moment is to lower the burden of VS loading newly built assemblies jsut to compile the others.
Lastly, for now, I can easily say that hanging for only 1.5 mins is getting off very lucky. There are people with much much worse build times due to things like this ;)
Some troubleshooting idea's that have not been mentioned:
Clean solution?
Delete Obj and Bin folders plus the .suo file? FYI, neither Clean nor Rebuild will delete non-build files, eg files copied during a pre-build command.
Turn off VS scanning outside files. Options > tools > environment > document > detect when file is changed outside the environment?
Rollback SVN history to confirm when it started to occur? What changed? If the project file on day 1 takes the same time, recreate the project, add all the files and build.
Otherwise could you please run Process Monitor and let us know what Visual Studio is doing in the prep-build stage?
Sounds silly, but remove all breakpoints first. It sped up my pre-build checks massively - still don't know why though.
Based on the (limited) information provided one possibility is that there could be a pre-build action specified in the project file that is slow to compile.
Try disabling platform verification task as described here.
If your individual projects are compiling correctly then all you can do is change order of compilation by setting dependent projects explicitly in configuration.
Try to visualize your project dependency hierarchy and set dependent projects. For example, if your business entities project is referenced in each project, then in configuration of each project, this project must be selected as dependent.
When an explicit build order is not set, visual studio is analyzing projects to create an order of building project. Setting explicit dependent projects wiki make visual studio skip this step and use the order provided by you.
With such an extreme delay on a single project and no other avenue seeming to provide a reason I would attempt to build that specific project while running procmon from sysinternals and filter out all the success messages. You could probably also narrow it down to just the file system actions as well. From your description I might guess that the files are being locked by an external source like the event collection or workflow management process services.
Other things to consider would be whether or not this is a totally clean build machine or if it has been used to perhaps test the builds as well? If so, is there a chance that someone mapped an IIS application path to the project directly or registered it as a service location?
If you run procmon and see no obvious locks or conflicts I would create a totally new solution and project and copy the files over to see if that project also has the same delay. If it does have the same delay I would create a sample project of the same type but generic data (essentially empty) and see if that too is slow. If the new project with the same files builds fine you can then diff the directories to see what the variance is that causes the problem (perhaps a config or project setting).
For me, thoroughly disabling code analyzers helped per instructions here:
https://learn.microsoft.com/en-us/visualstudio/code-quality/disable-code-analysis?view=vs-2019#net-framework-projects.
I thought my code analyzers were already off, but adding the extra xml helped.
Thanks Kaleb's for the suggestion to set "MSBuild project build [output|build log] verbosity" to Diagnostic. The first message took more than 10 seconds to display:
Property reassignment: $(Features)=";flow-analysis;flow-analysis" (previous value: ";flow-analysis") at C:\myProjectDirectory\packages\Microsoft.NetFramework.Analyzers.2.9.3\build\Microsoft.NetFramework.Analyzers.props (32,5)
Which led me to the code analyzers.
Just in case someone else trips into this issue:
In my case the delay was being caused by an invalid path entry in "additional include directories" that referred to a non accessible UNC location.
Once this was corrected, the delay disappeared.
I want to use debug symbols, but I am receiving the following error:
a matching symbol file was not found in this folder
What is this problem, and how to solve it?
One of the things I've ran into with was because debug was off on the project referenced where the code lives. In my case, I made a new configuration called "Developer" and by default debug was turned off.
Right click the project in question
Properties
Build
Advanced (right bottom corner)
Set Debug Info to full
Recompile
I had the same problem as #DmainEvent. Apparently the dll that I was using was not the same version as the pdb that I had just compiled, so I got the error message.
If you have this problem, try using the dll and pdb from the same compilation run.
The error I got was "a matching symbol file was not found in this folder" in the Debug => Modules window even after both the DLL and PDB were available and built together, so I was unable to debug into the target DLL referenced by my main project.
Posting this here in case it helps someone browsing with "Mixed Platform" build for target DLL. I did two things to get past this:
In the solution using the target DLL, Uncheck "Just My Code" in Tools => Options => Debugging => General => Enable Just My Code (JMC).
Check "Enable native code debugging" in target DLL solution in relevant Project Properties => Debug.
I tried all the possible solutions, finally it worked when I disabled the option Enable native code debugging under the Debugger engines of Properties > Debug.
I ran into this problem and the answer was simple.
Visual studio has two project level settings that can create .pdb files.
Linker: Configuration Properties -> Linker -> Debugging -> Generate
Program Database File = "xxxx.pdb"
Compiler: Configuration Properties -> C/C++ -> Output Files -> Program Database File Name =
"yyyy.pdb"
You want #1 for debugging. Forget about #2.
Give file #2 a different name than file #1 to solve this error.
I don't know why microsoft specifies #2 as a .pdb file. That is just confusing.
I have fixed my debug symbols, forcing them to match using this tool:
chkmatch tool
edit: the website is down now. the wayback machine helps: https://web.archive.org/web/20210205095232/https://www.debuginfo.com/tools/chkmatch.html
So, my problem was I was trying to debug my project and the debugger couldn't step-in to the in-house nugets sources. I had the source files of the nuget project. Still the visual studio didn't accept the pdb files I was trying to show it to.
Showing exact same error:
a matching symbol file was not found in this folder
So, what I did was I added this to the .proj file of the nugets project:
<DebugType>full</DebugType>
And created the dll and pdb file again using the rebuild option.
In the command line I ran:
.\ChkMatch.exe -m name_of_your.dll name_of_your.pdb
It said this:
Writing to the debug information file...
Result: Success.
Great success!
So, next, I referenced this dll instead to the proj I was trying to debug. I worked when I tried to load the symbol again.
Hope it helps.
Without more details as to what you're doing, it's difficult to go beyond "the debugger is looking for a symbol file which matches the compiled code, and couldn't find one in the folder where the compiled code lives."
Some things to think about:
Are you creating symbols as part of your compilation? (check the project properties)
Are you using a symbol server (if so, does it point to the right place)
Is this compiled code from a third party? In which case, as you apparently have the source, compile it yourself.
Consider clarifying your question if you want a better answer. Especially what do you mean by "I want use of Symbols".
For BizTalk (and other) projects, it could be because there's a version of the assembly you're trying to debug already in the GAC. When you run a unit test or hit F5 to debug, a new version is compiled locally. However, the version in the GAC is being used, and the newly created PDB doesn't match the DLL in the GAC.
One way around this is to deselect a build for everything except your unit test project using the Configuration Manager, as shown below:
Well, the solution depends on your specific problem. I tried everything that could be possibly found on Stackoverflow and other sites. One of the thread that I followed is this. That did not help too.
The problem was at once resolved when I noticed that my executable project did not contain a reference to the library that I wanted to debug. So I just added the reference to that project.
**PS: ** This problem might also arise because the assembly referenced by the executable assembly might not match that in the references. So in that case, you just remove the already existing reference and add the new one.
Hope this helps!
The same happen to me because the .pdb file of the project have not been copied to the debug\Bin folder, so the symbols could not be loaded from the .pdb file.
You must rebuild your project and manually copy the symbols (.pdb file) to the debug\Bin folder of executable project.
I was trying to load symbols for a installed nuget package published on our local dev server. I had to uninstall and add a normal reference built from the code instead. This worked for me. Just remember install the original nuget package again once finished debugging.
If it works for you, try to embed debug symbols in the dll itself, so the symbols are loaded automatically. This worked for me in netcoreapp3.1 and net5.0:
<DebugType>Embedded</DebugType>
<EmbedAllSources>True</EmbedAllSources>
Beware that you may find this in documentation:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
but it does not work.
I ran into this with Visual Studio 2022, tried the most of answers here. Fixed by switching back to Visual Studio 2019, seems like a bug in 2022.
My issue was a bit simpler to resolve, but still the issue the question asked. At first, I was not publishing the pdb file with the nuget package another project was using. Once I confirmed that, I removed the nuget package from my project and readded it from our network nuget source. That still didn't let Visual Studio pick identify the PDB location.
Then I noticed that if you select one of your nuget packages, ( Project --> Dependencies --> Packages --> Choose nuget package), there is a Path property. I checked that location and it pointed to %USERPROFILE%.nuget\packages. The pdb was not at this location and the Date Modified was older than the latest package I published. Once I deleted the folder for the given package version, removed it from my project, and re-added it, the latest .dll and .pdb file were added to this location.
After that, I was able to step into the code of my nuget package and had no further issues.
To get the nuget project to produce the pdb file in the first place, I added <IncludeSymbols>true</IncludeSymbols> inside of a PropertyGroup within the csproj file as other answers had directed.
Once I rebuilt that nuget project, it generated 2 *.nupkg files:
Namespace.x.x.x.x.nupkg
Namespace.x.x.x.x.symbols.nupkg
I found this was because the Properties => Debug => Start Action was set to Start external program instead of the Project. So the newly generated pdb file didn't match, because the actual exe was the wrong one.
I have had this problem recently as well.
Was able to fix it by selecting MyProject->Properties->Linker->Debugging->Generate Debug Info->"Optimize for debugging (/DEBUG)".