i have an application that has a dependancy on gdiplus. i need the application to also run on Windows 2000.
i want to include GDIPlus in the application directory, so that Windows 2000 computers will function, but if the machine is Windows XP, Windows Vista, Windows 7, etc, i want it to use the version of GDIPlus that ships, and is updated, with Windows.
Not possible?
From http://msdn.microsoft.com/en-us/library/ms997620.aspx Try adding the following to your manifest :-
<?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="Microsoft.Windows.mysampleapp" type="win32" />
<description>Your app description here</description>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.GdiPlus"
version="1.0.0.0" processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</assembly>
Won't it be easier to do it from the installer ? IF you are installing on Windows 2000 copy Gdiplus to application directory otherwise skip it.
From the GDI+ page:
Run-time Requirements
Gdiplus.dll is included with Windows
XP. For information about which
operating systems are required to use
a particular class or method, see the
More Information section of the
documentation for the class or method.
GDI+ is available as a redistributable
for Windows NT 4.0 SP6, Windows 2000,
Windows 98, and Windows Me. To
download the latest redistributable,
see
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm.
First hit on Google for "win2000 gdiplus".
Related
I have a ClickOnce server set up to host Outlook plugins. It automatically serves whichever the current version is to client machines.
When the plugin version changes, it updates perfectly. But if one of the configuration files within the version changes, I regenerate the manifest, but it won't update because it sees the .vsto pointing to the same version number. It ignores the change to the digital signature DigestValue:
<dependency>
<dependentAssembly dependencyType="install" codebase="MyAddin.dll.manifest" size="12345">
<assemblyIdentity name="MyAddin.dll" version="1.0.0.25" publicKeyToken="1234567890abcdef" language="neutral" processorArchitecture="msil" type="win32" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" />
<dsig:DigestValue>********************************</dsig:DigestValue>
</hash>
<dependentAssembly>
</dependency>
The only part of the sample that changes is the ********** (and obviously the .vsto signature at the bottom).
If I try to change any of the other values, it complains that the .vsto definition doesn't match the .dll.manifest definition, or the .dll.manifest definition doesn't match the target assembly. I don't want to require a new build just because a .config file changed.
How can I force Outlook to notice the manifest change so it will actually install, instead of thinking it's exactly the same with no changes?
I finally found the relevant question on Stackoverflow for someone trying to do the same thing:
How to update just one DLL in a ClickOnce installation?
All it requires is changing the version number. But it has to be changed in 3 places, or it will complain about not manifest versions not matching. This version number DOES NOT have to match any of the .dll files that are being deployed (even though it shows up under tag "assemblyIdentity", which is confusing). The version can be generated new each time any file changes to force an update (auto-increment, hashing, timestamp, random number, however you like).
I wasn't able to get it working before because I was only updating 2 of the references, not all 3.
First reference to this version number is found at the top of the application manifest:
<asmv1:assemblyIdentity name="MyAddin.dll" version="w.x.y.z" publicKeyToken="1234567890abcdef" language="neutral" processorArchitecture="msil" type="win32" />
Second place is at the top of the deploy manifest:
<asmv1:assemblyIdentity name="MyAddin.vsto" version="w.x.y.z" publicKeyToken="1234567890abcdef" language="neutral" processorArchitecture="msil" xmlns="urn:schemas-microsoft-com:asm.v1" />
And the third place is inside the deploy manifest:
<dependentAssembly dependencyType="install" codebase="MyAddin.dll.manifest" size="12345">
<assemblyIdentity name="MyAddin.dll" version="w.x.y.z" publicKeyToken="1234567890abcdef" language="neutral" processorArchitecture="msil" type="win32" />
I have a vb.net class library project targeting .net 4.5.1 framework. I am using Visual Studio 2013 community edition.
The project is a library consuming a webapi 2 REST API.
As a guide I am using this example.
Project's packages.config is the following:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net451" />
<package id="Newtonsoft.Json" version="7.0.1" targetFramework="net451" />
</packages>
Project's assemblies references are:
Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL
System
System.Data
System.Net.Http
System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
<HintPath>..\..\..\..\packages\Microsoft.AspNet.WebApi.Client.5.2.3\lib\net45\System.Net.Http.Formatting.dll</HintPath>
System.Xml
System.Core
System.Xml.Linq
System.Data.DataSetExtensions
app.config file is:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.1" />
</startup>
</configuration>
The problem is that System.Net.Http.HttpClient extensions defined in Microsoft.AspNet.WebApi.Client.5.2.3\lib\net45\System.Net.Http.Formatting.dll aren't loaded so functions like
System.Net.Http.HttpClientExtensions.PostAsJsonAsync(Of T)
and
System.Net.Http.HttpClientExtensions.PostAsXmlAsync(Of T)
aren't available.
In Object Browser System.Net.Http.HttpClientExtensions class defined in System.Net.Http.Formatting assembly under the System.Net.Http namespace are grayed out as you can see in the following screenshot:
I found several related questions like this one but the provided answers and suggestions in comments didn't work for me.
I tried several other recommendations from various internet sources, like for example replacing the reference of System.Net.Http.Formatting.dll found in Microsoft.AspNet.WebApi.Client package with the one found in the extensions assemblies area but didn't work either.
Now I am stuck and I don't know how to solve this. Any help will be highly appreciated.
EDIT
It appears that the grayed out classes in the object browser are just hidden classes (meaning they cannot be used directly in user's code) and have nothing to do with the problem described.
I am currently using the Microsoft BCL Async library (here) across a project with a large number of interdependent assemblies all compiled against .NET 4 Full Profile, I have had to use assembly binding redirect in each project to get it to compile (as per issue 2 here).
The problem I now have is that I consume one of these libraries from a C++/CLR DLL project, it does not actually need to use async but I have the following compilation error:
2>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5): warning MSB3268: The primary reference "ImInterface.dll" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "ImInterface.dll" or retarget your application to a framework version which contains "System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
I have added the same app.config file that I have used in all of the C# projects but it does not seem to be having any effect in the C++ project. Do I have to place it in a specific directory or perform any other steps to enable the app.config file to be recognised?
The content of my app.config file is:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.5.11.0" newVersion="2.5.11.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.5.11.0" newVersion="2.5.11.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Any suggestions are appreciated!
Regards,
Anthony
I had the same problem and as it turned out, <SpecificVersion>True</SpecificVersion> helped.
Before you continue reading, note that the problem seems to only happen when the C++/CLI project is built using the "Visual Studio 2012 - Windows XP (v110_xp)" platform toolset! That is if you don't need to create a DLL which is compatible with WinXP, switch to "Visual Studio 2012 (v110)" instead and you should be fine.
Let me elaborate my scenario:
I have a C++/CLI console application project (ConsoleAppCLI) targeted for WinXP (v110_xp). ConsoleAppCLI references a library (AsyncLib) which has Microsoft.Bcl.Async installed via NuGet:
[ConsoleAppCLI.vcxproj] (C++/CLI, .NET 4.0 v110_xp)
|
|
[AsyncLib.csproj] (C#, .NET 4.0)
|
|
[Microsoft.Bcl.Async] (via NuGet)
I had the exact same problem and the app.config didn't help either, but what did help was the following:
Unload ConsoleAppCli.vcxproj
Edit the vcxproj File directly
Find the reference to the library which has the Async nuget package installed (in my case, a <ProjectReference> to AsyncLib.csproj)
Between <ProjectReference> and </ProjectReference>, ADD THE FOLLOWING: <SpecificVersion>True</SpecificVersion>
Note however, that ConsoleAppCLI was my top-level project in the dependency tree. If you have Assemblies which depend upon the C++/CLI assembly which produced MSB3268, you likewise have to add <SpecificVersion>True</SpecificVersion> to the reference (e.g. if i had an additional C# library which has ConsoleAppCli as dependency, i would have to make the reference to ConsoleAppCli <SpecificVersion>True</SpecificVersion> as well).
This solution is coming from over here, by the way.
I've created an executable that's called by another app for processes that require UAC elevated privileges. If I build this project with the below manifest it requests UAC fine, if I add this projects output to my setup project it creates it without UAC?
<?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="CreateApp" type="win32"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Any idea why this is or if it's possible to have it as part of the setup project with the manifest?
Custom actions in InstallExecuteSequence already run as child processes of Windows Installer service. So they inherit their privileges and the manifest is not used.
To run a custom action with full privileges you should schedule it as deferred with no impersonation.
If you are not using the EXE as a custom action and you are just launching it from another process, make sure you use ShellExecute.
My installer deploys a configuration exe which is used to do some basic configuration on a windows service which is also installed. The exe also needs to create and write some registry keys. On a Windows server 2008 environment these keys can't be created. I have investigated and found that this is an Administrator privilege, and the exe isn't prompting for Admin permissions which are needed under UAC on 2008. I can work around this by right clicking the exe and running as Administrator. This isn't ideal however as its an extra step I need to notify our clients of performing. Are there any other ways of elevating the admin permissions when running the exe?
Put a manifest on or with the exe. I can tell you how to embed the manifest using Visual Studio if you let me know what version of that you're using. If you're not using Visual Studio, or you don't build the exe, then you can just put the manifest file in the same folder as the exe and that will work too. In that case the file must be named the same as your exe, with .manifest on the end, eg for foo.exe it's foo.exe.manifest. The content should look like this:
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
If you want to change the Windows User Account Control level replace the
requestedExecutionLevel node with one of the following.
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
If you want to utilize File and Registry Virtualization for backward
compatibility then delete the requestedExecutionLevel node.
-->
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
</asmv1:assembly>
Notice the possible values for requestedExecutionLevel are all here in a comment, and this one uses requireAdministrator. Now it will always elevate and therefore work for you.