I'm developing a library for use in other apps and this library has lots of debugging and logging statements thanks to NLog.
Is it possible to exclude the reference to NLog.dll when I switch to release mode?
Cheers,
You can manually edit the csproj file, and do something like this:
<Reference Include="NLog" Condition="'$(Configuration)' == 'Debug'" />
This only makes it reference that assembly in Debug. I wouldn't recommend doing this often though, because this behavior isn't reflected in the references list in Visual Studio when you change the configuration. It does work when compiling though
The only way I know is to take the reference out completely and call the assembly via reflection. Then, you should only log if the assembly loads.
I can't think of a good way to do this. Unless maybe you wrote a stub reference for NLog.dll. Since you are using the reference in your code I don't see how you could just remove it in your release.
Probably too late now but in the future you could write a class to wrap NLog.dll and then just change it in one place so it wouldn't actually log in the release version. Or have some sort of flag.
There is no reason for removing a reference in case you are sure that no code will be in use from that DLL. In that case you can simply remove DLL.
Why would you want to do that?
If you want to stop logging, you can programatically turn off the logging. The performance hit will be minimal. (I have had great success with NLog even when logging cross process.)
Otherwise, you need to wrap it as described above.
-Scott
Related
Is there a way to run my .fs file with either a breakpoint or a command like System.Diagnostics.Debugger.Launch() in it so that I can use FSI to examine values, apply functions to them, plot them, etc.?
I know this question has been asked before but I tried the answers and could not make them work. Clear instructions or a link to a write-up explaining the process would be of great help not only to myself, but also, I believe, to all beginners.
Unfortunately, you cannot hit a breakpoint and jump into FSI. The context of a running .NET program is quite different to that of an interactive FSI session and they are not compatible enough to just switch between one or the other. I can understand an expectation of this kind of debugging when coming from other dynamic/interpreted languages such as JavaScript, Python etc. It is a really powerful feature.
As you have already noted, you can use the VS immediate window but you need to use its C#-like syntax and respect its limitations. Also, since it's not F#, you need to understand the F# to .NET conversion in order to make full use of it.
If you use Paket for dependency management in your project you have another option: Add generate_load_scripts: true to your paket.dependencies. This will give you a file like .paket\load\net452\main.group.fsx, which you can load into FSI to get all of the dependencies for your project. However, you are still responsible for loading in your own source files and building up some state similar to what is found at your desired breakpoint.
To hit a break point, in visual studio or visual studio code, you just click to the left of the line number you want to set your breakpoint. This is very much a supported feature in .fs files.
My .NET program I want to use in Java depends on SlimDX, a managed wrapper over DirectX. I add it to the project references as normal without hiccup.
However, when it comes to using JNI4NET's build.cmd, I get a CS0400 error suggesting that it does not know what the hell SLimDX is, even though I referenced it properly and put it in the folder with proxygen. It cannot be found in the 'global namespace'.
This ('global::net.sf.jni4net.utils.Convertor.StrongJp2C')
is one of the offending lines.
Actually, I figured it out! It's simple, there is a -dp option in proxygen to add .NET dependencies.
I have a solution with some projects in that make up a library. I use this library in some of my other solutions. I do this by making a reference to the dll which is generated when the library solution is compiled. So far, so good.
Now I'm debugging one of those "other solutions". I see that I'm using a function from the library I built and I want to see what the code does. I hit F12 and I'm taken to a very useless page where I see only the signature.
I could add the library projects to my solution. this is unsatisfactory because when someone is editing the solution I want it to be clear that the messing about with the library bit is going to affect other programs. If I can describe my desire crudely, I would say I want the library solution to be show when I hit F12, but be read only.
How can I do this?
I think it depends on the complied option of the library. If the library is built without debug symbols, it would not be possible to debug inside in a normal human readable way. I suggest you compile/build the library with debug option. That may solve your problem.
HTH!
I know there are other questions regarding this subject, and I've looked at this question, but I'd like to see a little bit more discussion and information on both sides of this - is it a better practice to add a project to a solution and reference the project, or to add a reference to the .dll?
It's not much of a choice. If you have a solution with both projects then use a project reference. If your solution doesn't have the project then you have to use an assembly reference.
So the real question should probably be: do I create a solution with both projects? Yes, as long as the project is still in the debug stage and liable to require bug fixes.
If you only have the dll then you're stuck with a dll reference (obviously).
If you have the source then it's usually better to use a project reference. There might be cases where you have a utility library that's never going to change, but if there's the slightest chance of you needing a bug fix then having a project reference is going to make debugging a lot easier.
Summary - Project Reference by Project vs by DLL
Reference by project
code is visible
finds all references e.g. on a class (because code is visible)
better for testing (over all)
better for code redesign (impact)
Reference by DLL
code is hidden
separation between e.g. framework and project (for deliver of framework)
quicker compilation (because DLL is already compiled)
Well, project references are helpful when you are building and testing in both debug and release mode. If you directly add a DLL then you are locked into whatever that particular DLL was built as. The project reference allows this to be a build time decision.
Relative to your project architecture, you should always stick to projects within your problem domain. You should be using the GAC, if that is applicable to your environment.
I have a little problem with the creation of a user control.
Though I have made a control I want to use in another control.
As soon as I want to add the reference (would like to use it as compiled OCX) in the Component's list, the message "Wechselseitiger Verweis zwischen Projekten nicht zulässig" which means something like "Circular referencing between projects is not allowed"
Strange is that the control I want to use does not have any type of reference to the first project.
I've checked this using dependency walker which is shipped as a tool with Visual Studio, but it says as well that there's no reference to the other control. I've opened the project-files using a text-editor to check for referenced OCX, I didn't find any.
To avoid some comments: change to .NET or any other language is not an option.
Comment: Why ever, adding the uncompiled .ctl-file seems to work. For now I can continue my work. But anyways I'm interested in a solution and the reason why it doesn't work with the current constellation.
VOTE FOR CLOSE: I've been looking at all the files, well and now I've just simply added all control-files to the project instead of creating OCX. I'll give it up. Thanks to all...
It is possible for VB6 to get quite confused when you add references to OCX files. You should really be adding an OCX as a component instead of using Project References.