I am using MFC with VS2005 and I want to add the shield icon to a button. I created a control member variable for the button and in InitDialog I have
// BCM_SETSHIELD
this->m_ctrlStartact.SendMessage(0x1600+0x000C, 0, TRUE);
this->m_ctrlStartact.SetButtonStyle(BS_FLAT);
However, the shield does not appear. According to the Manifest, I have the correct version of the commctrl:
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
What can be the remaining problem?
SOLVED!!! For some reason I had the manifest file excluded from the build. Now it works :) :) – divB Jul 5 at 15:07
Related
We have a .NET DLL that contains several COM classes and objects that partner companies can use. We currently use regasm to register the COM classes in the registry. This has worked for years.
We now want to get rid of the COM registration and use side by side assemblies. I am currently trying to make this transition, but I seem to fail on the finish line. We deliver a sample application in C++ that uses our COM classes, and I try to get it to run without COM registration.
.NET DLL
In our .NET DLL, I have a class like this:
namespace MyNamespace
{
[ComVisible(true)]
[Guid("ef828ade-b459-4446-80db-956715588601")]
[ClassInterface(ClassInterfaceType.None)]
[ProgId("MyVendor.MyClass")]
public partial class MyClass
{
}
}
Application assembly
The C++ sample application that shall work with this COM class has a manifest like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32"
name="MyComDll.X"
version="1.0.0.0" />
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"
uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
</application>
</assembly>
DLL assembly
And the .NET DLL itself has a manifest to expose the COM class to the outside world:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32"
name="MyComDll.X"
version="1.0.0.0" />
<file name="MyComDll.dll">
<comClass description="MyVendor.MyClass"
clsid="{ef828ade-b459-4446-80db-956715588601}"
progid="MyVendor.MyClass.1"
threadingModel="Both">
<progid>MyVendor.MyClass</progid>
</comClass>
</file>
</assembly>
Using COM
I obviously use proxy names in my code samples above, but I made sure the all names in the original code are valid.
In our sample C++ code, we are getting the CLSID and creating the instance of the class this way:
HRESULT hr = CLSIDFromProgID(OLESTR("MyVendor.MyClass"), &clsid);
hr = CoCreateInstance(clsid, nullptr, CLSCTX_SERVER, IID_IDispatch, (void**)(&_pMyClass));
What goes wrong
I use some debug output to check the GUID that was returned from CLSIDFromProgID() and to check the return value. If the COM class is registered using regasm, the return value is S_OK and clsid is the same GUID that I specified in my .NET DLL for the class.
However, if I remove the COM registration and use the side by side assemblies with manifests as shown above, I also get the S_OK return value, but the GUID is something entirely different, and therefore I cannot create an instance of this class. I have not found the GUID I get from CLSIDFromProgID() anywhere - neither in the registry nor in my development solution.
Do you have any idea what I made have done wrong?
I know that my C++ sample application works in general very well with our COM objects, because it works flawless, if the COM classes are registered.
I checked every part of the manifests I created with Microsoft's specification and various guides.
I do not get any SideBySide errors in the Windows Event log, so I know that the manifests are properly formatted.
I do get an S_OK from CLSIDFromProgID(), so I know the ProgID is found - it just delivers the wrong CLSID.
I used the function StringFromCLSID() to compare the CLSID that was found by `CLSIDFromProgID().
First of all, I want to thank Joseph Willcoxson and Remy Lebeau for pushing me in the right direction!
I had a couple of minor issues in my manifests that I could resolve one after another. The big mistake I made was taking the assumption that a CLSID that I get from CLSIDFromProgID is the same as the one I specified in my .NET COM class. After it was pointed out that is not necessarily the case, I did not waste any further time and checked why calling CoCreateInstance failed. It turned several iterations of online research and testing to figure out the mistakes I made.
As Joseph pointed out, I should have used clrClass instead of comClass. I made mistakes configuring the clrClass. For instance, I used the same name for "name" that I used for "progId", but the "name" in a clrClass is the full namespace + class name.
For some reason about a quarter of our tests is not being run on TFS, build ends up green but reports only 3/4 saying all tests have passed.
I guess the problem is in some tested async code that perhaps crashes the test runner or keeps running on its own. Locally in VS all tests are passing fine.
Is there any way to enable crash dumps on TFS or how should I address this problem?
EDIT: In TFS web interface the Summary says "All 2217 tests passed" but in Diagnotics section, under the passed tests it says "Test run completed. 3228 tests executed" ...still not all (cca 3450 passing locally in VS2015)
I checked last builds on the server but as far as the history goes, they were already failing then (always different amonut have passed). So I can't trace that.
I also ran tests with vstest.console.exe and all is fine except 5 failed on long filepath (I disabled those with Ignore attribbute to no avail)
Edit by the bounty starter:
Sorry for the text in bounty box. Didn't think that line breaks would be swallowed. Providing the same text here.
I have exact same situation. Say I have 100 tests, but only say 60 are finally in the .trx file (say 50 passed and 10 failed). It would be great to solve this issue. Thanks!
<Target Name="CoreTestConfiguration">
<Exec Command=""C:\Program Files\dotnet\dotnet.exe" vstest /Blame /Diag:"$(SolutionRoot)##########################\bin\Release\diag.txt" "$(SolutionRoot)###########################\#################s.dll" /logger:trx;LogFileName="$(SolutionRoot)\#################################\Tests\bin\Release\TestOutput.trx" /Settings:"$(SolutionRoot)\############################################ests\bin\Release\#################sts.runsettings""
ContinueOnError="true"/>
</Target>
<RunSettings>
<RunConfiguration>
<TestSessionTimeout>4400000</TestSessionTimeout>
<TestTimeout>342000</TestTimeout>
<TargetPlatform>X64</TargetPlatform>
<TargetFrameworkVersion>
.NETCoreApp,Version=v2.0
</TargetFrameworkVersion>
<!-- same with net461: but different count of tests in final trx -->
<!-- <TargetFrameworkVersion>
.NETFramework,Version=v4.6.1
</TargetFrameworkVersion> -->
<DesignMode>False</DesignMode>
<CollectSourceInformation>False</CollectSourceInformation>
</RunConfiguration>
<LoggerRunSettings>
<Loggers>
<Logger friendlyName="blame" enabled="True" />
<Logger friendlyName="Console" uri="logger://microsoft/TestPlatform/ConsoleLogger/v1" assemblyQualifiedName="Microsoft.VisualStudio.TestPlatform.CommandLine.Internal.ConsoleLogger, vstest.console, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" codeBase="C:\Program Files\dotnet\sdk\2.1.503\vstest.console.dll" enabled="True" />
</Loggers>
</LoggerRunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="blame" enabled="True">
<Configuration>
<ResultsDirectory>
############################\bin\Release
</ResultsDirectory>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
which version Test Framework are you using?
It seems you want to build/run a dotnet core application.
In my opinion xunit works fine with dotnet core 2.x.
There is also a new version of MS Test framework available which has some interesting improvements. I read that in one of the latest dotnetpro article.
see also
Article, dotnetpro (GER)
Hopefully this will help you to solve this issue,
See ya
Leonhard
Computer A runs Windows 7 x64. Computer B runs Windows 7 x86. I am using Eclipse, Ant and MinGW-w64 to compile the file on Computer A. The file runs fine on Computer A, but on Computer B I get the following error:
The version of this file is not compatible with the version of Windows
you're running. Check your computer's system information to see
whether you need an x86 (32-bit) or x64 (64-bit) version of the
program, and then contact the software publisher.
The program is one file, main.cpp
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
MessageBox(NULL, "Goodbye, cruel world!", "Note", MB_OK);
return 0;
}
The ant script is as follows:
<?xml version="1.0" encoding="UTF-8" ?>
<project name="winsock" default="build">
<taskdef resource="cpptasks.tasks">
<classpath>
<pathelement location="E:\_dev\windows\MinGW\msys\home\windoze\projects\Winplay\lib\cpptasks.jar"/>
</classpath>
</taskdef>
<taskdef resource="net/sf/antcontrib/antlib.xml">
<classpath>
<pathelement location="E:\_dev\windows\MinGW\msys\home\windoze\projects\Winplay\lib\ant-contrib.jar" />
</classpath>
</taskdef>
<target name="build">
<mkdir dir="build" />
<mkdir dir="build/obj" />
<cc name="g++" objdir="build/obj" debug="${debug}">
<fileset dir="src" includes="*.cpp" />
<compiler name="g++">
<compilerarg value="-std=c++11" />
</compiler>
</cc>
<condition property="debugoption" value="-g -O0" else="-O2">
<isset property="debug" />
</condition>
<fileset dir="build/obj" id="objects" >
<include name="*.o" />
</fileset>
<pathconvert pathsep=" " property="objectslinker" refid="objects" />
<!-- Due to a bug in GppLinker.java in cpptasks.jar, we must exec g++ because GppLinker erroneously uses gcc, which breaks exception handling. -->
<exec command="g++ -std=c++11 -mwindows ${debugoption} -o build/winplay ${objectslinker}" failonerror="true" />
</target>
<target name="clean">
<delete dir="build" />
</target>
</project>
Why would the .exe work on my system, but not a system with the same Windows? Do I need to do something like statically link to the windows definitions that MinGW uses?
You are generating a 64-bit executable, and it's incompatible with any 32-bit version of Windows (notice that the opposite is not true, if you had generated a 32-bit executable, it would be compatible with 64-bits Windows...)
To generate a 32-bit version of your executable, check the "project options" on eclipse. You'll have to have -march=i686 somewhere in the antfile and the project options. It's possible that Eclipse has a checkbox/combobox for it on its interface...
I get this error when i use multiple dataCacheClients. Ive seen this question and this msdn question but at the time of AppFabric 1.0, multiple dataCacheClients were not possible. Microsoft added this feature in AppFabric 1.1 (see changelog), which I'm using currently. Any ideas on why I get this error? Here's my config file:
<configuration>
<configSections>
<section name="dataCacheClients"
type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core"
allowLocation="true"
allowDefinition="Everywhere"/>
</configSections>
<dataCacheClients>
<!--client 1 for caching-->
<dataCacheClient name="dataCacheClient1">
<localCache isEnabled="false" sync="NotificationBased" objectCount="100000"/>
<clientNotification pollInterval="5"/>
<hosts>
<host name="!2345623ghf1.fg.com" cachePort="22233"/>
</hosts>
<securityProperties mode="None" protectionLevel="None" />
<transportProperties maxBufferPoolSize="2147483647" maxBufferSize="2147483647" channelInitializationTimeout="60000" receiveTimeout="900000"/>
</dataCacheClient>
<!-- client 2 for session -->
<dataCacheClient name="dataCacheClient2">
<localCache isEnabled="false" sync="NotificationBased" objectCount="100000"/>
<clientNotification pollInterval="5"/>
<hosts>
<host name="!2345623ghf2.fg.com" cachePort="22233"/>
</hosts>
<securityProperties mode="None" protectionLevel="None" />
<transportProperties maxBufferPoolSize="2147483647" maxBufferSize="2147483647" channelInitializationTimeout="60000" receiveTimeout="900000"/>
</dataCacheClient>
</dataCacheClients>
<system.web>
<compilation debug="true" targetFramework="4.0">
</compilation>
<sessionState
mode="Custom"
customProvider="AppFabricCacheSessionStoreProvider">
<providers>
<add name="AppFabricCacheSessionStoreProvider"
type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
cacheName="default"
dataCacheClientName="dataCacheClient2" />
</providers>
</sessionState>
NOTE:
I'm using the DLL's found in .\Program Files\AppFabric 1.1 for Windows Server
More Error details :
I was finally able to get it working. There were some rudimentary but stupid mistakes I committed. Hopefully someone with the same issues would be able to get some guidance on this by my answer. The mistakes I committed/how it was rectified :
1) Check the DLL's CLR version
Always, I mean, always check the version of the DLLs you're using to refer in your consuming client. The DLLs to look out for are :
Microsoft.ApplicationServer.Caching.Core.dll
Microsoft.ApplicationServer.Caching.Client.dll
Microsoft.WindowsFabric.Common.dll
Microsoft.WindowsFabric.Data.Common.dll
Microsoft.Web.DistributedCache (this was what was causing me problems - I had an older version added in my solution; there's no need to refer this, just having this DLL in the same folder as the Caching.Core and Caching.Client is enough)
A good (or rather fail-proof) way to get the latest DLLs is to download & install Appfabric and get the DLLs from .\Program Files\AppFabric 1.1, add it in a folder inside your project and refer it from there.
2) DataCacheFactory must have a reference to what dataCacheClient its referring to
Just like how AppFabricCacheSessionStoreProvider must contain a dataCacheClientName attribute to refer to a specific cluster put in dataCacheClient, DataCacheFactory init in code must also contain a reference to the dataCacheClient which is gonna take care of caching :
DataCacheFactory _factory = new DataCacheFactory(new DataCacheFactoryConfiguration("dataCacheClient1"))
Thanks to everyone who helped in solving this issue!
I had this problem on one of our development machines and it was ultimately found to be installation of Windows Server AppFabric. My configuration was totally correct. The same configuration worked on all machines except one and once we un-installed Windows Server AppFabric from that machine and installed Microsoft AppFabric 1.1 version, the issue was resolved.
I'm also using AppFabric to store Asp.NET SessionState.
Can you use CMFCVisualManager with a dialog based application to change the applications appearance? If so how is it done?
The idea is to change the shape, colour etc. of controls such as push buttons using the MFC Feature Pack released with MSVC 2008.
No, can't be done, at least not if you're talking about the Feature Pack version. Version 10 of the BCGSoft libraries do have this functionality, see for example: http://www.bcgsoft.com/bcgcontrolbarpro-versions.htm and http://www.bcgsoft.com/images/SkinnedBuiltInDlgs.jpg. The MFC feature pack is more or less the previous version of the BCGSoft libraries, MS bought a license from them.
You need to add the Common Controls manifest to your project resources. Here is the code for the manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Program Name"
type="win32"
/>
<description>Description of Program</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
I think you can have some MFC-feature-pack features by implementing OnApplicationLook on your base CDialog (check Step 4 on this page). It might be better to implement the whole OnApplicationLook method, but you can test your application simply by adding this to OnInitDialog:
CMFCVisualManagerOffice2007::SetStyle(CMFCVisualManagerOffice2007::Office2007_Silver);
CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMFCVisualManagerOffice2007));
CDockingManager::SetDockingMode(DT_SMART);
RedrawWindow(NULL, NULL, RDW_ALLCHILDREN | RDW_INVALIDATE | RDW_UPDATENOW | RDW_FRAME | RDW_ERASE);
This is the least amount of code to enable the Visual Styles. You should be able to pop your CDialog into the frame easily. The IDR_MAINFRAME is a menu resource.
class CMFCApplication2Dlg : public CFrameWndEx
{
CMFCMenuBar bar;
public:
CMFCApplication2Dlg() : CFrameWndEx()
{
LoadFrame(IDR_MAINFRAME);
bar.Create(this);
}
};
class CMFCApplication2App : public CWinAppEx
{
public:
virtual BOOL InitInstance()
{
CWinAppEx::InitInstance();
CMFCVisualManagerOffice2007::SetStyle(
CMFCVisualManagerOffice2007::Office2007_ObsidianBlack);
CMFCVisualManager::SetDefaultManager(
RUNTIME_CLASS(CMFCVisualManagerOffice2007));
SetRegistryKey(_T("Local AppWizard-Generated Applications"));
m_pMainWnd = new CMFCApplication2Dlg();
m_pMainWnd->ShowWindow(SW_SHOW);
m_pMainWnd->UpdateWindow();
return TRUE;
}
};
CMFCApplication2App theApp;