I am developing an ActiveX control targeted at Windows CE 6 (on a Motorola Workabout Pro 4, if specifying helps). I have stage one working, in the sense that I can compile in Visual Studio, and have deploy using a simple CAB file.
However, I am finding it very hit and miss as to whether I can update the control on the device. If I perform a clean rebuild (ensuring that all intermediary files are removed beforehand) and redeploy the CAB file, I find that any changes aren't reflected in the deployed code: The output is unchanged, both in IE on the device, and when connecting and debugging via the Visual Studio 2008. Secondly, any breakpoints that I have added in the debugger no longer hit.
If I manually replace the dll file, this still has no effect. Even stranger, the control still continues to work if I completely remove the dll!
I'm a bit of a beginner when it comes to WinCE and ActiveX development, so any hints as to what I am missing here would be greatly appreciated!
In this instance, my problem was that I was failing to correctly register my dll with COM.
The simplest solution was for me to change the CAB file so that the the dll self-registered. In my case, this was done by changing a parameter in the CAB file properties for the dll in Visual Studio. This results in <parm name="SelfRegister" /> being added to the CAB _setup.xml file:
...
<characteristic type="%CE2%" translation="install">
<characteristic type="MakeDir" />
<characteristic type="output.dll" translation="install">
<characteristic type="Extract">
<parm name="Source" value="OUPUT~1.002" />
<parm name="SelfRegister" />
</characteristic>
</characteristic>
</characteristic>
...
Related
Is it possible to archive resources in msi file instead of creating .cab . What is the pros and cons of these two method
Embed Cabs: If you are referring to eliminating the external cab during MSI compilation for WiX visual studio projects, then you can achieve this by setting the EmbedCab attribute of the MediaTemplate element to "yes":
<MediaTemplate EmbedCab="yes" />
Here is an attempted "minimal changes" sample for how to build a basic MSI after creating a WiX project in Visual Studio. Suggest scrolling down to the actual WiX markup for the inline comments.
Why use External Cabs?: I rarely use external cabs if I can help it, but there are some advantages in some cases centering around build-speed and more reliable downloading (according to Arnson, see second link below). There may be further benefits. For example downloading a smaller cab for MSI repair operations if installation source is on a remote server - related to downloading. Cab files can make security software and anti-virus go spastic though.
How To: Optimize build speed
WiX and cabinetry
This question has been answered before BTW - in similar incarnations. See below.
Some Links:
Wix: single MSI instead of msi + cab
For the record: The embed cab behavior changed in WiX 3.8
What is the difference between Media and MediaTemplate in WIX?
I'm experiencing an odd and continously reproducable issue with Visual Studio 2013 Ultimate I'm hoping someone can help me glean insight into.
I recently deployed a C++ application, I am developing, to one of my older laptops. When executed, nothing happens. Almost literally. It simply ends execution and returns immediately. It's supposed to do quite a bit more. I thought I'd address this problem using Visual Studios automatic deployment and debugging abilities.
I like to take things in very small increments when trying new things, and the guides I've found on how to remotely debug and deploy have left me still feeling a bit confused/unsure.
So - I took the smallest step I could, by just selecting 'Remote Windows Debugger' and clicking that:
This expectedly pops up an error message:
Following the advice, I am unexpectedly greeted with this in the property pages:
I have absolutely no idea why this happens.
I know the cause, in a sense. By fiddling around I found that the debugging changes are contained within the Application.vcxproj.user file. Prior to running/configuring any remote debugging it looks as follows:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
after just attempting to run remote debugging, it looks as follows:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<DebuggerFlavor>WindowsRemoteDebugger</DebuggerFlavor>
</PropertyGroup>
</Project>
Reverting to the previous file state, the properties show up just like they're supposed to.
But why (seemingly) any change causes Visual Studio 2013 Ultimate to go a bit sideways is beyond me. I first stumbled on the issue by following one of the aforementioned guides where I started out by just updating the Deployment Directory in the properties and then clicking Apply. This caused Vs2013 to crash and lead to the same blank property page.
I should note that this issue occurs with a freshly created console application.
Anyone ever tried anything similar or got any suggestions as to how to perhaps cure this problem?
I need to create an application which needs to create files/folders in "C:\Program Files","Users[username]" and Sys32. Also the application needs to make some registry entry.
This application needs to work on Vista and higher. Also, on Windows Server 2003 and higher.
The above Operating Systems have the concept of User Account Control (UAC), where to access Program Files and writing in registry requires admin privileges.
I looked into many forums and found that using Microsoft SDK we can check whether the current user have admin privileges or not . But the function "CheckTokenMembership" fails for Vista and higher version of OS.
I also found a solution where manifest file can be used to tell OS in advance that the current application requires admin privileges. This is done using "requestedExecutionLevel" tag.
I am using Visual Studio 2005 to create the application. When we create an application in Visual Studio a default manifest file is created. Can I change this manifest file to include "requestedExecutionLevel" tag, so that my application always runs with admin privileges?
Is there any other method through which my application runs with admin privileges without asking user (admin or standard) to run my application as "run as admin"??
Thanks!
You should find an option for this in project properties Linker -> Manifest File -> UAC Execution Level. Set this to requireAdminstrator.
This will cause the default generated manifest to include the requestedExecutionlevel that you need, so that your users will be prompted automatically to elevate their privileges if they are not already elevated.
Acknowledgements and Introduction
This question helped me and I will help back with the knowledge I gained. Thanks to:
Lipika(The person whom asked the question) revealing that admin access was the reason why access to system directories were redirected to virtual directories. It was later clear that lack of admin access cause writing to certain registry keys to fail.
snowcrash09 for revealing the Visual Studio option for enabling require admin access. With further research on MSDN, I got the manifest to not embed into the executable under Properties>Manifest Tool; thus allowing me to read it.
Nayana's link to polynomial's answer is also good. Here I will borrow part of his answer in my demonstration.
Answer
As Lipika have stated, you require admin access, else Windows Vista and up will redirect you to a virtual directory. Which is great. Logically then your app should request admin access. You can let the user do it manually. If not, Windows provides many ways to do this programatically. The easiest way is to declare it in your app's manifest. Here I will dedicate instructions to individuals not using Visual Studio. If you are using Visual Studio, it is as easy as Properties>Linker>Manifest File>UAC Execution Level.
If you are using CodeBlocks for example; create a file called app_resources.rc. With CodeBlocks its very import that this file has the .rc extension, so CodeBlocks knows to compile it with windows resource tool. Copy the following code into this file, and add it to your project.
#include <windows.h>
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "adminAccess.manifest"
Create a manifest file called adminAccess.manifest. copy the following code to the file. Do not need to add this file to your project as it is reference from your rc 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="MyApplication"
type="win32"/>
<description>Description of your application</description>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Now you can compile your app and it will automatically prompt for admin credentials when run. It will return failure if admin access was not granted. On Windows Xp, you won't be prompted for any authentication.
Note that from here you can edit the manifest to add features such as visual styles for Windows widgets and DPI awareness.
If you are not using CodeBlocks. For example you are compiling from the command line. You pretty much have to compile the rc file with the Windows Resource Tool. In MinGw build tools, this is called windres.exe. It will compile a .res file. You then link this resulting file, with all the other files you will be linking at the linker stage.
Note that the rc file is a windows resource file and carries all the resources your app uses such as BITMAPs, ICONs, STRINGs, dialog template. Which will all be stored in the final executable. Which you can then load from the executable using Windows specific functions. This is pretty similar to what Android does.
I posted this on programmers first, but was told it belongs here. Funny, I didn't think so.
I have VS10 installed on a Windows Server 2008 R2 box, along with several other versions of VS dating back years. This is our production build machine.
When I load or create any C++ project and do a Rebuild or Clean, the IDE crashes. In the crash details, I see this:
I have seen other reports what seems to be the exact same error on the web (example). Other than the advice to open a ticket, I've seen no solution.
Has anyone else encountered and fixed this problem? I've opened a ticket with MS, but I'm covering my bases posting here as well.
EDIT:
I ran a logfile as suggested in comments. These are the only entries that occured after I loaded up VS, so this includes the build & the crash:
<entry>
<record>229</record>
<time>2010/12/01 19:35:39.804</time>
<type>Information</type>
<source>VisualStudio</source>
<description>Entering function CVsPackageInfo::HrInstantiatePackage</description>
<guid>{68939055-38E0-4D17-92CB-8909710D8178}</guid>
</entry>
<entry>
<record>230</record>
<time>2010/12/01 19:35:39.836</time>
<type>Information</type>
<source>VisualStudio</source>
<description>Begin package load [Windows Forms Designer Hosting Package]</description>
<guid>{68939055-38E0-4D17-92CB-8909710D8178}</guid>
</entry>
<entry>
<record>231</record>
<time>2010/12/01 19:35:39.882</time>
<type>Information</type>
<source>VisualStudio</source>
<description>End package load [Windows Forms Designer Hosting Package]</description>
<guid>{68939055-38E0-4D17-92CB-8909710D8178}</guid>
</entry>
How about contacting MS support directly? If this is blocking your work, you can push them to have it fixed (don't know about costs though, will probably depend on the product and specificities of your license...).
Alternatively, you can build your solution in the commandline: open a VS 2010 command prompt (shortcut is located somewhere in the start menu):
msbuild yoursolution.sln /p:Configuration=Debug
That shouldn't use devenv.exe (which is the thing crashing here) and invoke the tools directly.
The P8 bucket has a strange value, at least when compared to my machine. Check this post for a way to reverse-engineer the crashing method. The crashing assembly is stored in the C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.10.0\v4.0_10.0.0.0__b03f5f7f11d50a3a directory on my machine.
The P7 bucket (note that yours doesn't match the linked one) points to ServiceProvider.GetService(). The P8 bucket gives an IL offset of 0x4b but I see the method end at 0x41. However, I haven't yet figured out how accurate that can really be when the JIT compiled code gets optimized.
If this is anywhere accurate then you don't got much for a lead. A GetService() method is hopelessly generic. Although it certainly looks like it came up with a bad one that didn't survive a cast. It is the kind of stuff that addins can mess up.
Btw, this doesn't actually affect the build output, MSBuild.exe runs as a separate process.
For anyone still having this problem, the answer that fixed mine was that I had tried to completely wipe Internet Explorer from my computer- leading to the DLL call failure that crashed devenv.
Here is their official solution page:
http://support.microsoft.com/kb/983279
My question to Microsoft is... Why would a dependency on internet explorer to compile applications even make sense under any circumstances?
I'm developing a unit test project (let's say XXX.UnitTest) to test ViewModels in another project (XXX) in my solution. I can add the reference but when I build, an error states that it cannot find that same project (XXX)
Error 42 Could not load file or
assembly 'XXX, Version=1.0.2.66,
Culture=neutral, PublicKeyToken=null'
or one of its dependencies. The system
cannot find the file
specified. XXX.UnitTest
I did a clean rebuild of all projects in my solution.
I verified that the assembly with that version number (1.0.2.66) did exist in the path I was referencing.
I removed and re-added the reference both as a project and through the Browse tab.
I made sure that the version number was not specified in the csproj file.
I verified the referenced assembly with Dependency Walker.
I verified that both projects were targeting the x86 platform. (As suggested here Tips to help debug "Could not load file or assembly X or one of its dependencies")
Does anyone know what else can cause this problem?
Last week I had this same problem. It turns out my solution and projects were on a network resource. If I moved the solution to the local drive, the problem went away.
This problem happened regardless if I used a mapped drive or an UNC path.
This problem happened even with a Code Access Security Policy of "Full Trust" for the URL.
I believe the problem occurs on Windows XP computers and not Windows 7 computers, but have not tested or verified.
I believe it has something to do with the Share permissions.
If I try to use "offline folders" for the network resource, I get "access is denied".
-.
Setting NTFS permissions has no effect.
Adding user to administrators group has no effect.
I did not test to see if problem exists on removable local drives.
Work Around
Move solution and projects to a local hard drive.
Comment
I think this is a bug in Visual Studio 2010.
I came across this post while searching for the answer. Here is the solution. In the config file of QTAgent32.exe and devenv.exe in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, add the following element to the section:
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
This can be added to machine config file (C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Config\ machine.config) for all VS2010 tools. Be sure to run notepad as administrator to allow machine.config to save.
See this link for details: http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx
I have the same problem. I'm running VS 2010 on Windows Server 2003; both running within a VM on a Mac. My VS project is in the mac home folder (~/) which is mapped as Z:\ from the Windows side. At build time, VS studio generates an error saying it can't find the UnitTests.dll or one of its dependencies. I get the same error with a small test project. If I move the project to the Windows C:\ drive, the dll reference resolves and unit tests work. I tried to add the reference Blanthor mentions, but couldn't get it to work.