I have a property in config named to class like the following in my framework project:
public static string PropertyName
{
get
{
#if DEBUG
return GetValue("TestDevelopment");
#else
return GetValue("Test");
#endif
}
}
I've compiled my project. And I added this config.dll file to different project. But always returning GetValue("TestDevelopment") from this dll. I 've compiled Release mode but it's not working.
What's the problem to be? I hope, could tell...
If you compiled the dll as debug, and copied the file to a different one, it'll always be whatever it was when you compiled it.
You'll have to compile it in Release for it to be in release.
Related
I have a code running that successfully register Excel AddIn using C# Automation and talks to C++ though C# layer
// Tools -> Create GUID -> Register Format
namespace MyExcelAddins
{
[ClassInterface(ClassInterfaceType.AutoDual), ComVisible(true)]
[Guid("6F89542F-3DAC-471F-86DD-145F5E456968")]
public class MyExcelFunctions : AddInRegistrator
{
[DllImport(#"C:\Users\Ilya\Documents\Visual Studio 2012\Projects\UnmanegedTester\x64\Debug\")]
public static extern double AddNumbers(double a, double b);
public double SampleAdd(double a, double b)
{
double res = AddNumbers(a, b);
return res;
}
}
}
Here is the view of my solution where C++ project I added from another directory.
I was able to debug C# code and now I want to try to debug the C++ part. I set the debug property of C# project to
and when click run, the error I got is
If I uncheck "Enable Native Code Debugging", I do not have the error but of course cannot debug C++. My guess I'm missing something in the settings. Please let me know if anyone has an idea how to fix that.
If I continue debugging I can hit breakpoint in C# but not in C++
That error message is telling you that you don't have debug symbols for excel.exe, which is not surprising since it is a Microsoft program. You can continue debugging, and your code (which should have debugging information) will still be debuggable. For example, you can set a breakpoint in some of your code that will be called by Excel and the debugger will stop on it when it is reached.
As the title says, I want to change the .NET Target Framework Version for my C++ project. I'm trying to compile with the /clr command which I think should enable it?
Here's a screenshot:
I'm trying to build a DLL for use in Unity and I want to be able to select the proper framework.
I've tried changing the information in the .vxproj file but I can't find the right tag and when I add it myself it throws errors.
EDIT:
this is the code that contains the methods that can be called in C# to use the C++ code I've written before. I only edited the .h file of the CLR Class library (so the .cpp file is only including the header which should be fine I think)
#pragma once
#include "PortAudioManager.h"
using namespace System;
namespace PortAudioWrapper {
public ref class PortAudioManaged
{
private:
PortAudioManager* audioManager;
public:
PortAudioManaged() : audioManager(new PortAudioManager()) {
}
virtual ~PortAudioManaged() {
this->!PortAudioManaged();
}
// = Object.Finalize
!PortAudioManaged() {
delete audioManager;
audioManager = nullptr;
}
void openStreamManaged() {
audioManager->openStream();
}
void stopStreamManaged() {
audioManager->stopStream();
}
};
}
You should be able to follow the guide at https://msdn.microsoft.com/en-us/library/ff770576.aspx
The .NET framework you can target in C++ is dependent on the toolset you choose. You may find it easier to just download an older version of VS that supports the framework you're looking to work with.
In project file I just created the section looks like the below:
<PropertyGroup Label="Globals">
<ProjectGuid>{48ACEC98-3369-486F-9033-8C433D408570}</ProjectGuid>
<TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
<Keyword>ManagedCProj</Keyword>
<RootNamespace>ClassLibrary1</RootNamespace>
<WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
</PropertyGroup>
Using VS2015, I had to upgrade the .Net target of a managed C++ DLL from 3.5 to 4.5.1. In the Configuration Properties-General settings, the ".Net Target Framework Version" is greyed out and its value box is not editable.
Open the Name.vcxproj file in notepad.
Navigate to: "<"PropertyGroup Label="Globals" ""
Add: "<"TargetFrameworkVersion""v4.5.1"<"/TargetFrameworkVersion"
Save the updated project file, and reload into VSS2015.
NOTE: Remove the "" around the angle brackets.
Then when the project is reloaded into VS2015, you can see the .Net version listed in settings. In my case it was V4.5.1.
I'm writing a project using Win7 x64. Some part of my tests requires using SQLServer CE which only represents support for x86. I'm using Visual Studio 2010 Express and I gotta change platform target for my projects manually editing *.cproj files to run, for example, schema export test (NHibernate). Howcome I run a part of my tests depending on a platform target.
Thanks!
I don't know if there's a built-in mechanism in NUnit to handle this scenario, but at the very least you can use preprocessor directives.
For instance, create a "Debug x86" solution configuration, targeting x86. Then define the DEBUG_X86 conditional compilation symbol (in the properties of the project). Finally, surround your unit test with preprocessor directives:
#if DEBUG_X86
[Test]
public void Test()
{
// This test will only run when compiled with Debug x86
}
#endif
Edit: Actually, you don't even have to create a new solution configuration, as it's possible to define the conditional symbols depending on the platform (https://stackoverflow.com/a/1313450/869621). So define a WIN32 compilation symbol, and surround your test with it:
#if WIN32
[Test]
public void Test()
{
// This test will only run when compiled for x86
}
#endif
I have a TestClass.cs file that contains an interface, and a class, much like this:
namespace CPierce.CSharpBridge
{
[System.Runtime.InteropServices.Guid("3D08DF02-EFBA-4A65-AD84-B08ADEADBEEF")]
public interface ICSide
{
// interface definition omitted...
}
[System.Runtime.InteropServices.Guid("CBC04D81-398B-4B03-A3D1-C6D5DEADBEEF")]
public partial class CSide : ICSide
{
// class definition omitted...
}
}
When I compile this at the command line, and run regasm on it:
csc /debug /t:library TestClass.cs
regasm TestClass.dll /tlb:TestClass.tlb
I get a nice, big .tlb file suitable for including in a C++ project elsewhere....
10/27/2011 01:50 PM 3,616 TestClass.tlb
When I put TestClass.cs into a "Class Project" in Visual Studio, compile it, run regasm, the resulting .tlb is pathetic and nearly useless -- it has no interface, no method signatures, etc...
[Compiled TestClass.cs as part of Project "ClassProject" in Visual Studio]
regasm ClassProject.dll /tlb:ClassProject.dll
10/27/2011 01:58 PM 1,132 ClassProject.tlb
This is the same C# code in both cases, one being compiled with Visual Studio one at the command line, giving me completely different results.
What gives?
--
Update: Hans suggests that the [ComVisible(true)] attribute missing is causing the problem. Tried it, and it worked. But that still doesn't answer the question, why? Why do I get different results based on which compile method I use?
If you create a new Class Library in Visual Studio, the default AssemblyInfo.cs file includes the line:
[assembly: ComVisible(false)]
The command-line command you're using is only compiling your TestClass.cs file, so you get the default setting for ComVisible (which, judging from the available evidence, is probably true). When you compile from the IDE, you include AssemblyInfo.cs as well, so its explicit setting overrides the compiler's default.
Also check if your class has functions of accessor type public.
In our case, the project was working fine when it was being used from within the solution but when we extracted the logic to create a DLL, it stopped creating the TLB file with no indication on why...
So if you have a class like so,
public class tlbuser{
private void functionTLB(){
//function code
}
// rest of the class code
}
Ensure it is changed to:
public class tlbuser{
public void functionTLB(){
//function code
}
// rest of the class code
}
Is there a way to detect if your program was loaded through Visual Studio vs. whether it was started as a standalone executable?
Our software has a bug reporting feature to handle unhandled exceptions -- we need to be able to distribute debug builds to our beta testers, but we don't want the bug report to go off when we are in the middle of development, because the Exceptions are a lot more useful if VS catches them with a full stack trace, etc.
Right now, I'm disabling the bug report if Application.ExecutablePath includes bin\Debug or bin\Release, but I figure there is probably a more robust way of detecting whether the program was loaded through VS.
Obviously, we could set up a different build with some preprocessor macros, but for the sake of the question, assume that isn't a possibility -- I don't mind adding code, but I'm trying to make the fewest modifications to the build process, which is why command-line options are kind of a last resort as well.
If it matters, I'm using VS2003/.NET 1.1.
If you're doing this to determine if it is in any debugger (clarified by #JaredPar), you can use Debugger.IsAttached in the exception handler.
try
{
// ...
}
catch(Exception ex)
{
if (!Debugger.IsAttached)
{
ExceptionHandler.Frob(ex);
}
else
{
throw;
}
}
Alternatively:
public static void Frob(Exception ex)
{
if (Debugger.IsAttached)
{
Debugger.Break();
}
}
I don't do .net development, but in java I have done this by passing a flag into the startup options of the application. So you could pass a debug flag into the app from the IDE, and then check for that, when the app is run as an executable the flag would not be present. I would be surprised if .net didn't have something similar.
I know this is old but the provided solutions are not very satisfying.
I used the following class instead:
using System.IO;
using System.Reflection;
public static class Program
{
public static string ExecutablePath
{
get;
private set;
}
static Program()
{
var assemblyPath = Assembly.GetEntryAssembly().Location;
var assemblyDirectory = Path.GetDirectoryName(assemblyPath);
if (assemblyDirectory.EndsWith(#"\Debug") || assemblyDirectory.EndsWith(#"\Release"))
{
string projectFile = Path.GetFileNameWithoutExtension(assemblyPath) + ".csproj";
var root = new DirectoryInfo(assemblyDirectory);
while (root.Parent != null)
{
if (File.Exists(Path.Combine(root.FullName, projectFile)))
break;
root = root.Parent;
if (root.Parent == null) // we could not find it (should not happen)
ExecutablePath = assemblyDirectory;
}
ExecutablePath = root.FullName;
}
else
{
ExecutablePath = assemblyDirectory;
}
}
}
Then you can just use Program.ExecutablePath. If you already have a class named Program you can just extend it by those properties and methods.
If running from Visual Studio it will give you the project path where the csproj-file resides. This is the executable path without the "bin\*\Debug" or "bin\*\Release" stuff.
If not running from Visual Studio it will give you the path where the executable resides.
The solution is independent of debug settings, other attached debuggers or build configurations. The only important thing is, that your configurations are named "Release" and "Debug".
Note: As Troy Gizzi mentioned in the comments, this solution only works if you run the executable from another directory than the output directory. For my use case (simulate the deployment directory structure with the project directory as the root directory), this is a suitable solution. In general I copy my executable later to the deployment directory and expect the same behavior as if I run my program from within Visual Studio. Content and other dependencies are located relative to the project directory in my case.
Have you considered command line arguments? Run the program from Visual Studio with a --no-exception-handling flag (or whatever sounds appropriate), and don't handle exceptions if that argument is passed in. When you start the program elsewhere, without this argument, it'll behave normally.
Instead of tracking by process tree, I would add a configuration flag that enables the reporting feature. The flag can always default to "true" unless you are in your DEV environment then you set it to "false".
Sometimes the application is started outside the debugger and the debugger gets attached later. (Doubleclick on a file where the application is assigned to ...) I use this code to wait for the debugger attach.
using System.Diagnostics;
Process[] procName = Process.GetProcessesByName("devenv");
if(procName.Length > 0)
MessageBox.Show("Wait for debugger attach");