Develop Reference

MS Visual Studio subproject compilation prebuilt events IF condition error

My solution has two projects: c++ dll and c# web.
Dll project has pre-built event like this
IF 2 == 1
(
echo ERROR: Dll building error
)
And, obviously, this condition not interrupts building process and it finishes with success, if I run it for dll project.
But..
the Web project depends on the dll and therefore uilds it, in turn, by MSBUILD.exe command in it own pre-build event. That is, as a result, pre-build parent (MSBUILD for web) following by nested pre-build childs (IF for dll).
. And if I try to build web project, it interrupts with message Dll building error (from the dll project pre-built event) after child dll project by MSBUILD.exe (in web pre-built event) has built with success!!! - result dll file has appeared in output dir!.
What it's means? Child pre-build event conditions incorrectly interrupts parent build process?

The problem appears to be that you're misusing MSBuild. The proper way to handle "subprojects" is to use a Solution. In this solution, you have both projects, and a project dependency from the web project on the DLL. You build the solution, and that's one MSBuild command. Therefore, the C# web project does not need to start another MSBuild command.
MSBuild, when using a solution file, sees the real dependencies and handles build failures correctly. Note that a "echo ERROR" in a pre-build event is just text on a screen, not a build failure. You'll need to exit /b 1 the pre-build step to stop the build

Running and debugging Powershell modules in Visual Studio 2017

I'm developing a Powershell module in C#, in Visual Studio 2017.
I am a bit surprised that the developing-experience is so bad in terms of running and debugging so I'm trying my luck here.
The way it works for me now is as follows:
Implement the module
Compile
Start a new Powershell window
Navigate to the bin/debug folder
import the compiled DLL (import-module)
Run the commands
Close the Powershell window (as otherwise I cannot rebuild the project as the DLL file is locked)
Fix bugs, and go back to step #2
In case I need to debug the code, I use VS2017 attach to process and debug the code (after step #5).
That is not ideal in terms of DX and I would like to have something better, as close as to this:
Implement the module
Compile
Press F5 (start)
Powershell window opens up with the module loaded
Run the commands
Breakpoints hit pause the program like we used to
How do I achieve that?

I managed to get this work with help of above comment from #Glenn:
Start your debugging with external program
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
and the parameter line
-NoExit -command "Import-Module '<path to your module>'; "
With this you can now start with F5 -> get a powershell window with your already loaded module and the Debugger is attached to this process.
But you have to be careful if your binary module is written to target .NET Standard. In this case it seems that the debugger (VS2017 15.8.9) is not able to detect which run-time modules to load. So no breakpoints hit at all in this scenario! My quick workaround here was to add another project with Console App targeting .NET framework 4.xy and use this other project as start project with above settings. Now my workflow exactly mirrors your second sequence (1-6). Unloading the dll is no issue because stop debugging does end the process.

Stepping through VB6 COM object wrapped by .NET Class

I have a VB6 object that is wrapped by a .NET class. As far as I recall it is possible to step through a VB6 object by simply running the VB6 library and inserting a breakpoint at the desired location.
However this does not appear to be working in my case. I have attempted to recompile the VB6 object and re-reference it in my .NET project but this doesn't appear to have helped.
Where do I go from here? Is there a way to insert Debugger.Launch() equivalent into a VB6 project? Any help would be appreciated!!

Lifted from robgruen's blog:
If you are using interop to call into a VB6 ActiveX dll or exe and you
need to debug your VB6 project you may find yourself having both
VS.NET and the VB6 IDE open. This can certainly be far from
efficient.
Typically you set your VB6 project to “Wait for the Component to be
created” and you launch your .NET app and then hit breakpoints within
the VB6 component. Well, there’s an easier way to do this. You can
actually debug your VB6 component within VS.NET. Here’s what you need
to do:
1) Build your VB6 project with symbols.In VB6 open up your vbp file
and goto “Project->Properties.” Select the “compile” tab and check
“Compile to Native Code.” Then select the “No Optimization” radio
button and check “Create Symbolic Debug Info.”
This will generate a .PDB (Program Database) file along with your
.EXE. This file contains the debugging information so the VS.NET
debugger can line up source and hit breakpoints, etc. (Make sure you
have binary compatibility on your VB6 dll set or you’ll have to drop
and re-add your reference to the VB6 component in VS.NET.)
2) Open your .NET project in VS.NET.
3) Go to the project properties and select the “Configuration
Properties->Debugging” property page and enable unmanaged debugging.
For VB.NET projects this option is “Unmanaged code debugging” and for
C# is “enable unmanaged debugging.”
4) Select the property page for the solution.
5) Add to the “Debug Source Files” an entry that points to the path
where the source code is for the VB6 component.
6) Add to the “Debug Symbols Files” an entry that points to the folder
where the .PDB file is that was generated in step 1.
7) You should now be able to open your .bas, .cls, .frm, etc. files in
VS.NET and you can put breakpoints in the file. Once you debug the
debugger will stop on those lines of code.

Is there a better way to run a c++ makefile from a c# project?

I have a project in c# which uses bindings to use some c++ code. The c++ code consists of multiple DLL's which are compiled using a makefile. Currently I'm trying to run the makefile using a pre build event which calls nmake. However to get it to find nmake I need to have a line in it like the following:
"$(DevEnvDir)..\..\VC\vcvarsall.bat"
Also, even with that line present, nmake doesn't produce any output at all in the output window. Neither does it throw any errors. I tried redirecting the output to a file and it doesn't write anything. I have reproduced all steps in my pre build event in a normal shell and it works fine. I figure I must be missing something. Why doesn't Visual Studio give me a Visual Studio shell for my pre build event? Is there a better way to run this makefile? If not, has anyone got any ideas as to why nmake isn't producing any output?
EDIT: D'oh! nmake wasn't running as I forgot to add 'call' to the start of the line, i.e:
call "$(DevEnvDir)..\..\VC\vcvarsall.bat"

I often build non VS-project (sometimes with nmake, sometimes with other build tools) as a part of a larger solution build.
I tend to make a simple batch file, which sets up the environment and then runs the make.
I call the batch file from a build event (often post-build on my stuff) - usually with a CD on the front:
cd ..\.. && armbuild
Never (that I can remember, anyway) had any problem with the output appearing in the console window.

Debugging of native code

I have a C# Service that is calling a C DLL that was originally written in VC6.
There is a bug in the DLL which I am trying to inspect.
After having a nightmare trying to get debug to work I eventually added the dll to the VS2005 solution containing the C# Service and added the necessary _CRT_SECURE_NO_WARNINGS.
The debug version of the service is registered using 'installutil.exe' tool.
I can get the debugger to break just before the line where the dll is entered via a call to System.Diagnostics.Debugger.Break();.
I found some instruction on the net regarding stepping into debugging unmanaged code, and enabled the 'Enable unmanaged code debugging' check box, I've also tried turning on the Options->Debugging->Native 'Load DLL exports' and 'Enable RPC Debugging' (even though it's not COM). I've also copied the debug dll and .pdb to the same bin directory as the service.
However the unmanaged code is not being stepped into which is what I really need.
UPDATE: I found the Debugging Type in the DLL properties and set it to 'Mixed' as per suggestion on several sites but to no avail.
UPDATE2: My project now emits the debug dll and the pdb to the same directory as the debug service. Still unable to debug the dll.

Try setting the unmanaged code as the startup project. I know it doesn't make sense but I remember this working for a very similar project.
Since the DLL doesn't have an associated executable, when you try to run it will pop up asking what app to run. Browse to your C# app and then you should be good to go.
Happy debugging!
EDIT: it's been a while, but I think the debugging type Mixed is correct

In the end I created a console app and recreated all the prior calls just to make sure the call would act as it did in the actual service with the actual parameters once it got there.
I chronicled my fix and the resultant code at my site.

There is a workaround in Visual Studio 2013. Run the application from cmd line. When System.Diagnostics.Debugger.Break(); is hit, a Visual Studio Just-In-Time Debugger window should pop out. Check "Manually choose the debugging engines.", click "Yes" and ensure that "Native" engine is checked. Click "OK". Now you should be able to step into the native code as if you would by running the code from within VS.