I have a solution that uses a native .DLL library that is wrapped by a .NET .DLL with a C# GUI.
All my plumbing works just fine in Debug mode. The moment I try going to Release mode, I get a whole whack of error messages, largely to do with the .CPP files in the native library. Errors include the following:
definition of dllimport function not allowed
TRACE_DEBUG_METHOD_CALL: identifier not found
a lot of undeclared identifiers in my main .CPP file (eg: DLLAPI_Release: undeclared identifier)
I have to admit that the Properties configuration for a C/C++ project is overwhelming so I wonder if there is one or more simple settings somewhere that I simply need to modify.
ALSO, is there a book out there that is devoted to the project properties window in VS2010 specifically? I have a few books but none really spend anytime on what is obviously a very crucial component to serious app development.
I appreciate any assistance anyone can offer. Thanks!
This is not unlikely to happen when you made a bunch of setting changes but didn't also make them for the Release build. Easy to forget, the first time anyway. You can easily tell which settings were changed from the default, they are displayed in bold type. Step through the setting pages, flip back-and-forth with the Configuration combobox in the upper left corner.
About 15 minutes of your life, not counting the thinking time you need because the setting should be different for the Release build. Start another instance of Visual Studio with a dummy project to verify that.
Trying to compare the property pages can be a beating. My recommendation would be to open the property pages for your project, select the Debug configuration, and under "C/C++", select "Command Line" and copy the command line options into a text editor, then do the same for the Release configuration and see where they differ. You'll need to do the same for the "Linker" command line.
Some of the differences will be intentional (e.g. debug flags should be set for the Debug configuration), but you should be able to spot things that should be the same but are not.
Actually tracking down where the command line options are set can be a bit of a pain, especially if you are using property sheets to manage common properties between projects, but generally you should be able to track them down just by looking through the different options on the different pages.
As for a reference, the best reference is the actual compiler documentation on MSDN. There is a section containing all of the documented compiler options and one containing all of the documented linker options.
The property pages are just a GUI frontend for setting these various options. When you select one of the properties in the property pages, it should say in the help box at the bottom of the dialog which compiler options are used by that property.
Related
We used to arrange our Files with a Tool called NArrange.
Unfortunately, this doesn't get advanced anymore and thus doesn't work with the new C#-Expressions like String-Interpolation etc.
I'd like to use ReSharper for the arrangement and also tried to work trough the instructions: https://www.jetbrains.com/help/resharper/10.0/File_and_Type_Layout.html?origin=old_help
From what I've seen in them and in the VS, there is a default Template for every Type and the "Full Cleanup" should apply it.
But just nothing happens.
I also tried to change some stuff on the Default Layout and created my own Profile as suggested, but it keeps happening nothing.
Since I can't get any information from Mr. Google, I guess I'm doing something wrong, which is pretty obvious?
Got it: ReSharper can't make use of other Regions than the ones defined in the File Layout: As soon as a to ReSharper unknown Region is in the File, it seems to stop the whole process and just does nothing.
I'm writing a Visual Studio editor plugin. I'd like the editor to behave similarly to other editors: if the edited file changes outside the IDE, I want the proper dialog window to be displayed and the document reloaded (if needed).
The IVsPersistDocData interface contains methods IsDocDataReloadable and ReloadDocData, but during debugging, they were never called in this scenario.
There is a combination of IVsFileChangeEx and IVsFileChangeEvents interfaces, but reaction to changing files outside the IDE seems to be so generic, that I guess I shouldn't need to manually monitor the edited file. Or should I?
It seems, that there actually is no automatic mechanism for doing that and using IVsFileChangeEx and IVsFileChangeEvents seems to be the only solution.
http://blogs.msdn.com/b/dr._ex/archive/2005/11/01/487721.aspx
http://msdn.microsoft.com/en-us/library/Microsoft.VisualStudio.Shell.Interop.IVsFileChangeEx.aspx
I have a localized WinForms application. To avoid a large number of iterations in the translation procedure, I have given our translators software to allow them to edit the .resx files directly.
This has worked great for the resource files that are not tied to UI components (Forms/Controls), but for forms and Controls the resources don't seem to be getting updated. What I mean by this, is that at design-time all resource strings are correct (Text/ToolTips et al.) and I can see the correct translations - when I run the application (debug or any other release) the translations are not being updated, why?
Thanks for your time.
Edit1. The plot thickens further. There are two buttons that are not being updated at all when I change their components (button text, tooltip or any thing governed by the underlying resource file). Lets say I change the button text from 'Lock Workbook' to 'Lock Workbook GG', then the new text shows in the designer and the .resx files (both in the .resx designer and the code behind) but when I run the code (in debug or release mode) the button text is not updated!?
If I update the button next to the button I updated above, this does change the text in the running application?? This is baking my noodle as I fail to see where the old text is being stored and why for a sub-set of buttons their component text is not getting updated!?
Any ideas are warmly welcomed!
Edit2. I have tried to delete the .suo and clean and recompile. I have also removed the troublesome form from the solution and re added it.
So that you can see this strange behavior, here is one of the problematic buttons ('Lock Workbook GG') and a normal one ('Set as Default Workbook GG').
Now at run-time I see
Maybe your build settings are wrong?
This is what I have for my dll.
I have given our translators software to allow them to edit the .resx files directly
That certainly was not a good idea. Any professional translator will know how to tackle .NET resx files. Even if they don't have any of the tooling that's traditionally used by translators, like SDL Passolo, then they would still fall back to the standard Winres.exe utility included with the SDK.
Whatever you wrote probably has a bug. Quite hard to reverse-engineer from the question what that bug might be. Other than that the .resx file for a Winforms form is quite different from the one you get from Resource File project template or the resource designer. There are lots of resource naming tricks to avoid ambiguity between the form's properties and the properties of its controls. Get a name wrong and it won't work right.
Don't write your own, at least ask them to use Winres.exe if necessary. It is free.
The bindings to the button are made in the Designer File of the related form, have you checked whether there are some issues? Try removing the code that sets the ressource and re-add it via the designer.
Probably this has something to do with the CopyLocal property. Please check if these are TRUE for these resource files. If not, set them to true, otherwise, after succesfull compilation, they are not being copied to the output directory.
For the tl;dr crowd:
What is causing type names to be written to the output window if it isn't Console.WriteLine or Debug.Print statements in the code? Is it the Visual Studio debugger? and
How can I turn it off?
Background and details:
I am trying to debug a program that imports CSV files into a database. Recently, I changed how I include 3rd party library dependencies. Previously, I was referencing the downloaded binary files. Now, if a 3rd party library has source code available, such as NHibernate, the project is included in my solution to be compiled along with the projects I have written myself.
Since the change, I am seeing a lot of single lines containing only a type name in the Output/Debug window that I didn't used to see before. My program is a data importer, and the main loop is causing these lines to appear 1000s of times, slowing down debugging and polluting the output window. Specifically, there are a lot of lines that say this:
NHibernate.Driver.NHybridDataReader
I have traced the code, and it seems that this is displayed whenever NHibernate is reading results back from the database. However, the line isn't output in code by the NHibernate library, so it must be coming from somewhere else. My guess is that the Visual Studio Debugger is writing it to the output window, similar to what happens during assembly binding.
I have tried compiling the NHibernate project in Release mode and everything else in Debug mode, but that didn't fix it. I also tried unchecking "Enable the Visual Studio hosting process" for just the NHibernate project, but that didn't work either.
In summary, my questions are:
What is writing type names to the output window if it isn't Console.WriteLine or Debug.Print statements in the code? and
How can I turn it off?
What my question is not
My question is NOT about a better way to write the data importer program so that the needed data is preloaded from the database. I know the code I have written is slow; in this particular case, in production, that is okay. What I want is to stop polluting the debug window with tons of unneeded type information. The work loop of my program causes the types to be written 1000s of times for long CSV files, which makes the output hard to use, and slows the debugger down as it tries to sync the output window. THIS is what I am trying to prevent. But I'm not sure how to do that, because I'm not even sure where the messages are coming from.
It's difficult to make suggestions without being able to see the code, but what I would do to debug it is install the trial version of RedGate's Reflector and use it to add breakpoints to the Debug.* and Console.* functions. If one of the breakpoints is hit, you can trace back up the call stack to find what is actually adding the lines to the output. If none of those methods are causing the lines to be added, maybe add breakpoints to DefaultTraceListener and TextWriter.
I haven't come across anything else which can add messages to the Visual Studio output window at run time.
I think this is irrelevant, though it solved my seemingly unrelated problem a while back (I had automated tests randomly failing and printing to console). I had to uncheck Visual Studio's "Enable property evaluation and other implicit function calls" under the Debugging menu in Options. Sorry if this is off topic/unhelpful!
EDIT: Also, have you tried changing the 'Output Window' settings in the Debugging section? You could maybe turn all debug output off and print your own debugging to a file.
I'd like to release some updates for a WinForm program, but to date I have simply released an all-new compile. People have to un-install the old version and install the new version.
EDIT: I'm using an auto-generated InstalWizard. It preserves my file strucutre and places the [PrimaryProgramOutput] in a particular directory. I forget what this is called.
I bet there's a way to get around this, but I don't know what it's called. As you may guess, searches for "updates" "new version" "install" and the other obvious things I've tried have generated an impressive number of irrelevant results. >_<
I suspect this process has a particular name, which should point me in the right direction, but if it doesn't please link to a tutorial or something.
I see from the tags you are using C#. Visual Studio can create Setup projects for these kind of tasks. The setup projects als contain a property RemovePreviousVersion, which will remove a previous version if the versioning of your setup is correct and the GUID of the application stays the same.
See this link for more information:
http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
ClickOnce deployment is a great solution most of the time...
You can deploy to the web and when ever your users start the application it will check for updates and automatically update the application if there is a new version available.
It can also be configured not to update automatically but only to notify the user that there is a new version available and allow the user to control the update process.