I have an scenario that I have to build my project and copy generated dll to another path.Because In our company every one builds his project and copy his dll to another path and IIS run all dll together as a single web application(we copy our dll by post build scripts).
But it takes me alot of time and for seeing every bit change I have to wait alot of time to build,copy,reset IIS(some time) and see my result.Is there any way to config Msbuild to build just part of my code that changed and I see my result in shorter time as like as debug mode in visual studio.In debug mode you change your code and msbuild can rebuild new changes and shows you just in time.
note : in development environment every one has a local IIS with compatible dll of others.
note : Because of some custom settings, no one can run his project in visual studio by run debug
I appreciate of any help
Related
I work with project written in C#, I use Visual Studio 2019. There are .aspx views in the project. I need to exclude them from build but they should stay in the solution since some tests are linked to them. I use build action: none, according to official documentation that means: The file isn't part of the build in any way. https://learn.microsoft.com/en-us/visualstudio/ide/build-actions?view=vs-2022 . But after the build, when i navigate in browser to these pages - browser starts to download them, which means that they were included into build.
What am I doing wrong? How to exclude these files from the build?
The ASPX files are compiled at run-time from the original location in the source code for local debug/run scenarios (there are no copies for those). From developer's point of view these files already have "Build:none" for local debugging purpose. Changing action to "none" does not in any way impact the original content/location of the file so it will still be located at the same place at the run-time on dev box and render at run-time as if it still built.
Where you'll see an impact of "Build:none" is "published" version of the site - with "none" files will not show up in published version and hence will not work from "published" version.
Debug (or Release) folder of my Desktop application when copied to another location does not run the exe. It issues no errors, but simply hangs the system for a second or two, but returns to normal straight away, as if nothing had been run.
Does Visual Studio 2015 create dependencies in upper hierarchy of Debug as well? My installer created using Wix was not running the intended exe and i thought it was Wix's problem. But then i tested it by copying the full Debug folder in a temporary subfolder and the app was not running even from there. It can only happen when it has dependencies present in places other than the Debug folder (because system resources (dlls) are accessed from absolute path of C: drive, so they would always be available.
Could there be something wrong in your manifest file or some other settings file? Some relative path pointing to a folder in your source hierarchy? Maybe it is just an image file or some sort of settings file that is missing? Or it might be something completely different.
A I wrote in your other question, one approach for hard-to-debug dependency scenarios is to just bite the bullet and run a thorough procmon.exe session (that is a direct hotlink to the live sysinternals tool share, clicking it will start the download instantly - just so you are aware).
You can see a quick description of how to use this tool in this question: Registering a CPP dll into COM after installation using Wix Msi installer. The key is to set an include filter which will show only events you need to see - basically for your own application.exe should suffice I believe.
Many find this procmon-stuff overkill, and don't want to deal with it - but trust me, it almost always reveals something unexpected (not always useful however).
As before this answer may also be worth a quick skim (on dependencies in general): After creating MSI Installer for WPF app in Visual Studio 2017, EXE does nothing. I would at least try the Dependencies.exe tool - even if it is a bit "beta-ish". You can download from here: https://github.com/lucasg/Dependencies/releases.
And certainly double-check the modules view in Visual Studio which I describe in the linked answer (Debug => Start Debugging, then go Debug => Windows => Modules). It should show whatever was loaded to run your project interactively.
I am trying to debug my DLL Class Library on Windows, but I am not able to get the debugger to stop in the source code.
Environment: Windows 10 Pro x64, Visual Studio Premium 2013 Update 5. Project is a .NET 4.5 Class Library. The executable is actually instantiated by another .exe before it calls my .dll. (I don't have source access to either of these .exes.) The .dll is in the same dir as its calling .exe, but that is not the Class Library project directory. I know my .dll code is executing, as I create new windows in my code, which are opening.
I have tried Debug->Attach to Process... in VS2013, and I connect to the calling .exe process, but the breakpoint I have set in my code never is hit, despite that code definitely being called. What am I missing here?
EDIT: This is not a duplicate of another question:
Not getting any error message
Not intermittently working
The assembly is confirmed as being loaded and executed
Your assembly might be compiled for release or compiled without any debug info. If you do things correctly, you should be able to debug by attaching to process. Another thing that can be, your code executes before you can attach to it. sometimes, especially in services, you put thread.Sleep into code, so this buys you some time to attach.
The issue turned out to be VS was not correctly figuring out what type of code to debug. In the Attach to Process window, I had to switch from Automatic to manually specify debugging Managed (v4.5, v4.0) code type in the Attach to: option, before attaching to the parent .exe process. I could then step through my source. (As it turns out, copying the .pdb file was not required - VS still uses the version of that file in the original project Debug directory.)
I'm working on a project that retrieves a number of Solutions from a team foundation server, to a temporary folder, uses Microsoft.Build.Execution.BuildManager.Build to build a release version for these Solutions, and cleans up the temporary folder with source code afterwards.
The problem arises when running my project with a debugger attached:
during the clean-up I get a system.UnauthorizedAccessException with message
"Access to the path ...\obj\release\CalithaLibrary.pdb denied".
Using sysinternals Process Explorer I found out that the lock was aquired by devenv.exe.
When I build a release version of my project and run it outside of visual studio the problem does not arise.
Any ideas as to why Visual Studio would aquire a lock of a PDB belonging to a project that was never opened by Visual Studio?
Edit: The first answer I received made me think I probably wasn't clear enough about the situation:
I'm debugging a project named "AutoReleaseService.exe" which uses Microsoft.Build.Execution.Buildmanager to build (but not run or debug!) a number of other projects, among which CalithaLibrary.
If I were trying to delete the AutoReleaseService.pdb from my own project, to which I did, in fact, attach the debugger, I'd understand, but the project to which the pdb file that gets locked belongs hasn't even been run on my machine, let alone debugged. I only built the project.
I'm debugging a project named "AutoReleaseService.exe" which uses Microsoft.Build.Execution.Buildmanager to build (but not run or debug!) a number of other projects, among which CalithaLibrary.
Well, CalithaLibrary looks like a DLL project, which is most certainly being used when you run AutoReleaseService.exe. It is straightforward - when the exe project is run, it uses all of the dll-s which it depends on. Visual Studio (devenv.exe) locks the .pdb files, because they are the link between the source code and the executable when you debug the application, and if you open the executable from outside of Visual Studio - they are not locked, because you do not need them then.
I'm starting to become pretty sure there's a bug in MSBuild here somewhere.
Luckily I managed to debug the last part of the application I needed to debug by excluding a few of the builds it was making, so it's now running in Release and does not encounter problems anymore.
Some information on why I think it must be a bug.
My application's workflow was something like this:
Create a temporary workspace on Team Foundation Server
GET a number of solutions/projects from TFS to a temporary folder
BUILD a number of these (configurable through xml but that's beside the point) to a different temporary folder
Clean up the temporary folder with source code
I tried setting MSBuild Options "DebugType" to none and "DebugSymbols" to false, but for some reason it kept outputting the Program Database files which is why I think there's a bug somewhere.
Whenever I skipped the "Building" step and skipped straight ahead to "Clean up" there were no locks on any files.
I am writing tests for an application using Outlook Redemption that absolutely must run 64-bit (it connects to windows MAPI and Outlook x64). Unfortunately, I cannot for the life of me make it run the test in 64-bit. I have tried using a .runsettings file (edited to indicate 64-bit) and a .testsettings file (also edited), and finally I have selected Test>TestSettings>Default Processor Architecture>64-bit, to no avail.
Every time, System.Environment.Is64BitProcess is false, and when I load the dll to connect to Outlook and MAPI I get the dreaded COM Exception: Wrong OS or OS version for application (Exception from HRESULT: 0x800401FA (CO_E_WRONGOSFORAPP)) which indicates that 64-bit Outlook is installed and the process trying to access it is 32-bit.
I have restarted VS 2012 after making settings changes as I have read somewhere that a restart may be necessary. Does anyone have any other suggestions? I could just write this as a console app that runs informal tests and reports their status, but my next step is to get these tests integrated into the automated build. Any help would be greatly appreciated.
Edit
Screenshot of Host Settings page in .testsettings
Experiment
Interestingly, I did a little experiment. I created a new solution with a single console app project. I put a public method in there that just returned true. When I ran the console app, and paused execution, I looked and indeed it is running 64-bit; no problem there. I then added a test project, created a single test which called the method. I also added var is64 = Environment.Is64bitProcess and put a breakpoint after it.
Predictably, without changing any options, is64 was false. I chose the 64-bit default architecture from the dropdown under test, then cleaned the solution, and ran the test again, same result, running 32-bit. I restarted VS2012, cleaned, built, same result. I created a testsettings file and referenced it in the Test menu, clean build, same, restart,clean, build same. I created a runsettings file, set <TargetPlatform>x64</TargetPlatform> , referenced that in the test menu, ran through it all again, and came up with the same results. QTAgent32.exe continues to run the process, and absolutely refuses to heed my demands that it run 64 bit.
I swear, if I have to delete QTAgent32.exe and rename QTAgent to that name, I will. I am not above cramming my wishes down the computers throat when it wants to be obstinate. Please, if you dont want to see me mistreat a workstation, someone show me what is going wrong. Think of the computers.
If you use VS2012, then you will be able to select your platform x64 through test settings as below;
In this example I am referring to .runsettings file.
the settings are
But if wish to run your test through command line you need to use vstest.console.exe instead of MSTEST as it doesn't support for x64 test.dlls
you will find vstest.console.exe at "C:\Program Files (x86)\Common7\IDE\CommonExtensions\Microsoft\TestWindow\"
Please note below steps
Open CMD
Navigate to "C:\Program Files (x86)\Common7\IDE\CommonExtensions\Microsoft\TestWindow\"
execute vstest.console.exe "C:\Projects\Test\Test.Automation.Specs.dll" /InIsolation /platform:x64
Note : Test.Automation.Specs.dll is your test project and you need to define full path
I hope this help
I ran into the same issue just now. Here are the steps you can follow to fix the problem.
Switch default processor architecture for unit tests from x86 to x64: Go to Test->Test Settings->Default Processor Architecture->x64.
Change the Build settings for the unit test project to x64.
Clean the solution then rebuild the solution. Your unit tests should now show up in the test explorer, and you should not run into this issue anymore.
References
Link to MSDN reference which explains how to resolve the issue.
This is a bit out of my scope, but the configuration settings for both projects are set correctly, right? You have them set to build for AnyCPU or x64?
Just trying to Occam's Razor it out... I know I've been frustrated too many times by configuration settings that VS just magically decides to change on me.