Microsoft has added yet another string type to this cruel world. Now you have HSTRING in addition to all those char*, char[], wchar_t*, wchar_t[], BSTR and various typedefs. If you want to get HSTRING's value - use Immediate Window debugger feature, type WindowsGetStringRawBuffer(rcx, nullptr) to display the value held in rcx register (function's first argument for x64).
Adding libraries to your Visual Studio C++ projects might be cumbersome if you aint doing "Hello World" applications. You need to specify include paths, library paths, resource paths etc. For each individual configuration BTW. Then you start the application and realize you must copy dll/pdb/whatever files to your output directory. Sure you google the solution and end up having Custom Build Tools or Steps for each item in your library. That sucks, believe me. But there is much simpler solution! As always on thig blog...
Let's say you have reusable library in your (D)VCS repository. Codejock Xtreme Toolkit Pro is a good example of such a library. Lets make it reusable in seconds.
The answer is a property sheet file for you library:
<?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ImportGroup Label="PropertySheets" /> <PropertyGroup Label="UserMacros"> <CodejockDir Condition="'$(CodejockDir)' == ''">$(MSBuildThisFileDirectory)</CodejockDir> <IsDebug>$([System.Text.RegularExpressions.Regex]::IsMatch($(Configuration), '[Dd]ebug'))</IsDebug> <CodejockArchSuffix Condition="'$(PlatformArchitecture)' == '64'">x64</CodejockArchSuffix> <UnicodeSuffix Condition="'$(CharacterSet)' == 'Unicode'">U</UnicodeSuffix> <DebugSuffix Condition="$(IsDebug)">D</DebugSuffix> <CodejockBinDir>$(CodejockDir)\Bin\vc$(PlatformToolsetVersion)$(CodejockArchSuffix)</CodejockBinDir> <CodejockItemName>ToolkitPro1531vc$(PlatformToolsetVersion)$(CodejockArchSuffix)$(UnicodeSuffix)$(DebugSuffix)</CodejockItemName> </PropertyGroup> <PropertyGroup> <IncludePath>$(CodejockDir)\Source;$(IncludePath)</IncludePath> <LibraryPath>$(CodejockDir)\Lib\vc$(PlatformToolsetVersion)$(CodejockArchSuffix);$(LibraryPath)</LibraryPath> <SourcePath>$(CodejockDir)\Source;$(SourcePath)</SourcePath> <LocalDebuggerEnvironment>$(CodejockBinDir);%(LocalDebuggerEnvironment)</LocalDebuggerEnvironment> </PropertyGroup> <ItemGroup> <CustomBuild Include="$(CodejockBinDir)\$(CodejockItemName).dll"> <Filter>Libraries\Codejock</Filter> <Command>xcopy /Y "%(FullPath)" "$(OutDir)"</Command> <Outputs>$(OutDir)\$(CodejockItemName).dll</Outputs> </CustomBuild> <CustomBuild Include="$(CodejockBinDir)\$(CodejockItemName).pdb" Condition="$(IsDebug)"> <Filter>Libraries\Codejock</Filter> <Command>xcopy /Y "%(FullPath)" "$(OutDir)"</Command> <Outputs>$(OutDir)\$(CodejockItemName).pdb</Outputs> </CustomBuild> </ItemGroup> <ItemDefinitionGroup> <ResourceCompile> <AdditionalIncludeDirectories>$(CodejockDir)\Source;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories> </ResourceCompile> </ItemDefinitionGroup> <ItemGroup> <BuildMacro Include="CodejockDir"> <Value>$(CodejockDir)</Value> </BuildMacro> </ItemGroup> </Project>
Let it have Codejock.props name and reside in you library root folder.
This is just an ordinary MSBuild file which can act as a property sheet page for
you C++ projects. Now you can just open Property Manager and Add Existing Property
Sheet to your project. This automaticaly adds necessary environment and build process
changes to make the library work for you. Thats it. And it doesnt fucking overwrite
your unchanged dll files every time you hit Build command!
You probably want to understand how does this work? Well, go and RTFM for MSBuild system.
The only unpleasant thing about this - Solution Explorer displays all those referenced files as childrens of your Visual Studio project (filter element is ignored).
Нашел на днях отличный плагин для Visual Studio - Codekana. Основная функция - покраска кода. Очень удобно. Я вообще считаю, что такие вещи должны поддерживаться изначально самим редактором.
Вышла 4-я версия ORM тулкита от IdeaBlade. Она построена на Entity Framework, небольшой обзор на сайте производителя.
The SDK documentation for StyleCop 4.3 is now available for download, here.
This documentation explains how to create and install custom StyleCop rules, how to integrate custom settings into the StyleCop settings dialog, and how to create a wrapper for hosting StyleCop in a custom build environment.
Greetings from JetBrains!
We are pleased to announce the general availability of ReSharper 4.0!
This release brings you the most up-to-date support for C# 3.0, including LINQ, and Visual Studio 2008 in general. The major upgrade also features multiple new usability and productivity-boosting tools, such as standard class library annotations, solution-wide analysis (for C#), versatile code cleanup, new automated refactorings, new and improved code-editing capabilities, and more.
Complete product information about JetBrains ReSharper is available at http://www.jetbrains.com/resharper.
ReSharper 4.0 is available for a 30-day free trial download at http://www.jetbrains.com/resharper/download. No evaluation licenses are required.
New customers can purchase ReSharper 4.0 online at http://www.jetbrains.com/resharper/buy.
Please NOTE: All those who have purchased ReSharper 3.0 or ReSharper 3.1 after December 21, 2007 qualify for a free upgrade!
Wishing you develop with pleasure!! Team JetBrains
Почти все разработчики, использующие Visual C++, сталкиваются с файлом stdafx.h, в который можно положить много-много различных директив препроцессора. И так мало понимают, зачем это нужно и как с этим работать...
Вы, наверное, слышали о понятии Precompiled Header
. Precompiled Header
- это механизм, позволяющий компиляторам сократить время сборки приложения путем прекомпиляции
редко меняющихся файлов исходного кода приложения. В первую очередь - это библиотечный код, точнее заголовочные файлы.
Рассмотрим программу Hello World
:
#include <tchar.h> #include <iostream> int _tmain(int argc, _TCHAR* argv[]) { std::cout << "Hello World!" << std::endl; return 0; }
А теперь внимание: после обработки этого файла прекомпилятором, его размер возрастает до 996 килобайт! Я повторюсь: 996 килобайт, из которых 854 составляют полезный код (остальное - комментарии), а размер рабочего кода программы - аж 142 байта. Похоже, для компиляции нашего простейшего cpp-файла компилятору прийдется изрядно потрудиться. Причем над каждым cpp-файлом проекта.
Естественно, лучше предварительно обработать неизменящиеся куски кода, превратив их в удобный и быстрый формат для последующей обработки в составе исходного кода приложения. Компиляторы Visual C++ и GCC поддерживают такую обработку и она носит имя Precompiled Header
.
Мастер создания проекта Visual C++ предлагает свои услуги по настройке Precompiled Header. В простейшем случае, среда дает разработчику возможность выбора - использовать этот механизм или нет. В большинстве случаев использование Precompiled Header настраивается автоматически.
Что же мы получаем при автоматической настройке Precompiled Header средой разработки Visual Studio?
stdafx.h
В этом файле содержатся, как правило, только директивы препроцессора, подключающие внешние заголовочные файлы.
stdafx.cpp
Состоит из единственной директивы #include "stdafx.h" и используется для генерации Precompiled Header. Следующая картинка демонстрирует свойства файла stdafx.cpp, раздел C/C++, подраздел Precompiled Headers:
#include "stdafx.h"
При этом компилятор игнорирует любой текст до момента включения stdafx.h! А в случае его отсутствия - выдает ошибку fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?
Опираясь на вышенаписанное, последовательность действий простая:
CommonIncludes.hCommonIncludes.cpp и добавить туда одну строчку - #include "CommonIncludes.h"CommonIncludes.cpp#include "CommonIncludes.h" в начало соответствующих cpp-файлов исходного кодаКак правило, в stdafx.h, созданный визардом, лепят все, что можно влепить. В результате в каждый cpp-файл включается совершенно ненужный ему контент! Поэтому, логично включать в stdafx.h только наиболее используемые заголовочные файлы.
Директивы прекомпилятора в stdafx.h распостраняются одинаковым образом на все cpp-файлы, включающие данный заголовочный файл. Бывает, необходимо настроить поведение библиотеки (в рамках отдельного cpp-файла или группы таких файлов) путем определения каких-то символов перед включением соответствующего заголовочного файла. Первое, что приходит на ум, - определить эти символы в cpp-файле и еще раз включить заголовочный файо библиотеки. Но, нет, я же писал, что компилятор игнорирует любой исходный код до строчки #include "stdafx.h"! Соответственно, повторное включение заголовочных файлов будет просто проигнорировано. Получается, нужно удалять включения заголовочных файлов библиотек из stdafx.h и добавлять их в каждый отдельный cpp-файл.
Также, проект не ограничен одним Precompiled Header! Вполне можно содзать пару файлов Subsystem1Includes.h, Subsystem1Includes.cpp, отвечающих за отдельный Precompiled Header в рамках некоторой группы файлов исходного кода.
Компилятор Visual C++ имеет ограничение на размер pch-файла. На практике это выглядит следующим образом:
error C3859: virtual memory range for PCH exceeded; please recompile with a command line option of '-Zm130' or greater fatal error C1076: compiler limit : internal heap limit reached; use /Zm to specify a higher limit
В таком случае спасет опция компилятора /Zm:
Source Analysis, also known as StyleCop, analyzes C# source code to enforce a set of best practice style and consistency rules.
Появился Oracle 11g ODAC and Oracle Developer Tools for Visual Studio.
Состав:
Visual Studio по функциональности и удобству заставляет курить в сторонке все IDE для плюсов. Но, некоторых мелочей, все же, очень не хватает. А иногда они просто хорошо спрятаны...
Довольно часто приходится вставлять куски кода вида hr = GetLastError();, запускать Error Lookup чтобы
прочитать человеческим языком что же произошло. Я уже давно пользуюсь одним из более удобных способов:
HRESULT, то окошки дебаггера Visual Studio (Watch #, Autos,
Locals etc) автоматически отображают в колонке Value строку ошибки вместо кода.err или @err отображает текущее числовое значение
GetLastError(). А для отображения строки вместо числа нужно применить форматирование - добавить через
запятую hr. Пример: @err,hr.
Visual Studio поддерживает множество форматов. Подробнее - Visual Studio Debugger --> Format Specifiers in C++
@eax,hr
расскажет нам в чем беда.Есть и другие псевдопеременные -
$handles, $vframe, $TID, $ENV, $CMDLINE,
@registername или $registername, $clk, $user. Приятно, а?
Допустим, в своем проекте MyProgram Вы используете некую библиотеку MyLibrary. Как обычно, подключаете
MyLibrary.h, MyLibrary.lib. Все компилируется отлично, а вот при попытке
запуска...
---------------------------
MyProgram.exe - Unable To Locate Component
---------------------------
This application has failed to start because MyLibrary.dll was not found. Re-installing the application may fix this problem.
---------------------------
OK
---------------------------
Если вы столкнулись с этой ошибкой - читайте дальше.
Сообщение об ошибке говорит, что MyLibrary.dll was not found
. Windows ищет dll в следующих местах:
Вероятно, ни в одном из вышеперечисленных источников MyLibrary.dll не была найдена. Соответственно, для решения проблемы следует положить MyLibrary.dll в одно из этих мест. Пункты 3 и 4 отшибаем сразу, а остальные случаи разберем подробнее.
Наверное, это папка bin/Debug проекта, где линкер создает MyProgram.exe. MyLibrary.dll туда можно скопировать путем создания Post Build Event. Мне эта идея не нравится.
Можно попросить отладчик менять стартовый каталог запускаемого приложения. Для этого есть настройка проекта Debugging->Working Directory. Мне эта идея тоже не нравится.
Можно изменить пользовательскую (или системную) переменную PATH (System Properties->Advanced->Environmental Variables->User variables for %USERNAME%), добавив туда каталог с MyLibrary.dll.
Но мне больше всего нравится следующий трюк: 
Microsoft Line Of Code Counter - порядочно полезная утилита!
Из названия понятно, что считает строчки кода. Но это не аналог Project Line Counter т.к. позволяет
Гибко настраивается через XML файл. Изначально поддержка всех основных MS-языков. Работает как в составе Visual Studio 2005 так и отдельно.
Товарищ, работающий менеджером в Microsoft, сообщил, что Visual Studio 2008 зарелизится где-то в декабре 2007-го года (что, в принципе, отражает догадки о дате релиза). А, вместе с релизом, мы получим возможность посмотреть исходники .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, ...), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), WPF (System.Windows) и даже с комментариями! Спустя месяц планируют добавить WCF, Workflow и LINQ.
Исходники можно будет скачать, как отдельный пакет, или же позволить Visual Studio 2008 скачивать их (вместе с файлами отладки) по мере надобности.
Должен заметить, что я, как и любой другой любопытный разработчик, потратил много времени как на декомпиляцию фреймворковских библиотек, так и на изучение Rotor Shared Source. Часто, без этого тяжело понять, как работают некоторые классы. Скажем, хорошие знания Remoting появились у меня только после просмотра исходников.
Единственное, чего бы не хотелось, - так это good old MFC development style, когда разработчик проводит 90% своего времени в исходных кодах MFC, тщетно пытаясь понять в чем проблема и как это работает.
Окна задочены наверху, включен Auto Hide - списки "Modules" и "Processes" пустые!
Сообщения
Все комментарии
