I'm new to Wix and I have ran into a problem that I'm obviously not able to solve on my own, so any help will be very much appreciated.
Quick background:
I'm representing a software vendor building a comprehensive suite of SOA based applications for deployment in large enterprises. Our architecture consists of many layers which may be installed/upgraded independently, so I'm building several installers, composing from the ground up (like: platform, core framework components, service layer, business layer, application layer, etc.).
Software versions:
-Wix 3.5.1309.0 (wix.dll)
- Visual Studio 2008, .Net 3.5
- Build OS: Windows 2008 R2 Standard 64 bit
- Deploy OS: Windows 2008 Standard 32 bit
My problem is in regards to installing .Net assemblies in COM+ applications. I keep on getting the error "Could not install type library". I have been reading all the documentation that I can find, and I have been google'ing for several days now. I find quite a few posts on the topic, but I'm still not able to resolve the issue.
To isolate the problem I have extracted the issue into a separate installer. First I run the main installer:
1. Installs all assemblies into GAC, including the one to be installed in COM+.
2. Create local users and groups.
3. Create the target COM+ application, including roles etc.
4. Installs the target assembly, and the companion typelib, in a folder (to remove any GAC lookup issues)
This installer I can install/repair/uninstall, everything works fine.
Then I run the minimum installer containing only the issue, which tries to:
1. Install the assembly in an existing COM+ application (server), referencing the pre-installed .dll and .tlb.
The install fails, and the log is showing:
MSI (s) (AC:64) [19:16:01:127]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI1BAB.tmp, Entrypoint: ComPlusInstallExecute
ComPlusInstallExecute: ExceptionInfo: Code='0', Source='System.EnterpriseServices', Description='Could not install type library 'c:\Program Files\MyManufacturer\ComPlus\WDA.ServiceProviders.Update.11.tlb' into application 'WDA.ServiceProviders.Update.11'.', HelpFile='', HelpContext='0'
ComPlusInstallExecute: Error 0x80020009: Failed to invoke RegistrationHelper.InstallAssembly() method
ComPlusInstallExecute: Error 0x80020009: Failed to register .NET assembly
ComPlusInstallExecute: Error 0x80020009: Failed to register assembly, key: MyAssembly
ComPlusInstallExecute: Error 0x80020009: Failed to register assemblies
Action ended 19:16:02: InstallFinalize. Return value 3.
I also notice that the rollback removes the COM+ application, even though it was not created by this installer.
I can install the assembly manually, using the Server Manager, from the same physical file that the installer is referencing. After manually removing the component from the COM+ application, then the installer works!
Also, why do I have to supply a typelib in the first place? The EnterpriseServices.RegistrationHelper is generating the typelib on the fly anyway.
This is the minimum test installer that is failing:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:complus="http://schemas.microsoft.com/wix/ComPlusExtension"
>
<Product Id="48EDB258-BD84-47EF-94A2-B4950EE48139"
UpgradeCode="F29B8EBD-DFD1-4B7E-96FF-86842CAAE4A4"
Name="ComPlusInstalls"
Language="1033"
Version="1.0.0"
Manufacturer="MyManufacturer">
<Package Id="ABA41719-BC28-4A57-BA9A-58F4F3B2194F" InstallerVersion="200" Compressed="yes" />
<Media Id="1" Cabinet="WixTest.cab" EmbedCab="yes" />
<complus:ComPlusApplication Id="MyApplication" ApplicationId="1FCF220A-A1FE-44FE-BE91-B37341BA6D4A" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="MyManufacturer" Name="MyManufacturer">
<Directory Id="INSTALLLOCATION" Name="ComPlus">
<Component Id="MyComponent" Guid="6D46A007-6669-487B-BAA0-DFA7314C141D" KeyPath="yes">
<complus:ComPlusAssembly Id="MyAssembly" Type=".net" Application="MyApplication"
RegisterInCommit="no" DllPathFromGAC="no"
DllPath="[INSTALLLOCATION]WDA.ServiceProviders.Update.11.dll"
TlbPath="[INSTALLLOCATION]WDA.ServiceProviders.Update.11.tlb"/>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
<Feature Id="MainFeature" Title="WixTest" Level="1" Absent="disallow" InstallDefault="local">
<ComponentRef Id="MyComponent" />
</Feature>
</Product>
</Wix>
Cheers,
-Nils
I have the same problem. Ive tried Wix 3.5 and 3.6.2012.0 and it hasnt worked with either. It works if
I use regsvcs first
Delete the component
Run the msi and click on Ignore when a message comes up about the application already existing
Did you manage to find a solution?
First, you might try upgrading to the latest version of WiX v3.5. There were some bug fixes in COM+ at the end. If that doesn't work, take a look at the open bugs around COM+. There are a couple known issues with the installation code due to complexities in COM+.
If any of those bugs sound applicable maybe you can help fix them with the community?
Related
I wrote a tool at work in .NET 5.0 that I now have to give to a non-developer to use. Unfortunately, no matter how I publish it I can't get it to run on her computer. Currently I have it set at:
Configuration: Release | Any CPU
Target framework: net5.0
Deployment mode: Self-contained
Target runtime: win-x64 (checked that, she definitely has Windows 10 64-bit)
But when she runs it on her PC she gets:
Failed to load the dll from [C:\Users\username\Desktop\Release Builder\hostfxr.dll], HRESULT: 0x800700C1
The library hostfxr.dll was found, but loading it from C:\Users\username\Desktop\Release Builder\hostfxr.dll failed
- Installing .NET prerequisites might help resolve this problem.
https://go.microsoft.com/fwlink/?linkid=798306
I, of course, checked the link and she has above the minimum version of Windows 10. What gives? I'm use to either building web applications or just building console tools for myself. I figured self-contained would mean just handing over the contents of the publish folder.
I should point out, that the publish folder APPEARS to be correct... its over 230 files in there.
Can you try to publish with these settings?
Step 1:
Step 2: Open your .csproj and add these, or swap with yours.
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows</TargetFramework>
<PublishReadyToRun>true</PublishReadyToRun>
<PublishSingleFile>true</PublishSingleFile>
<IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<UseWPF>true</UseWPF>
// keep other info
</PropertyGroup>
I'm trying to run an webapp that is using some Azure SDK (and storage) apis but when I try to run it, I always get this runtime error.
I have the project on a Windows 7 box with Visual Studio installed and a bunch of SDKs and it works but on this new Win10 machine I'm starting it doesn't work.
msshrtmi.dll is present on the new machine on C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\bin\runtimes\base\x86 (and x64 and in runtimes\net45\base) but on the old machine it is also on
c:\windows\Microsoft.net\assembly\GAC_XX\msshrtmi and I can see on IIS that is from it's loaded.
If I manually copy msshrtmi.dll to my bin folder the project works just fine. I also know this file is required form Microsoft.WindowsAzure.ServiceRuntime.
On this new machine I'm trying to avoid installing Visual Studio and using only Jetbrains Rider to build and run the project. It can build the project fine but now it doesn't run because of this.
Does the file really need to be on my windows\microsoft.NET folder? What installer puts it there? Or should I just include msshrtmi.dll as a dependency on my project?
Any other solutions for this problem?
I tried a lot of the solutions on other answers I encountered for this similar problem with no luck.
Edit: tried on ISS express 8 and 10
There are several possible ways to solve this issue:
1.Copy the msshrtmi.dll manually to your project. For example in the \bin folder next to the WindowsAzure.Storage.dll.
2.Install the Windows Azure SDK on your server.
3.Change some configurations from app.config.
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<runtime>
<NetFx40_LegacySecurityPolicy enabled="false" />
</runtime>
For more details, you could refer to this article and this one.
I have Solution A which has a .NET Core 1.1 class library project. In the Package properties I filled all NuGet fields and selected to create the NuGet upon successful build. This project builds just fine and the NUPKG is created. BTW How can I automatically copy the generated NUPKG to a local directory (my own repository)?
Then I have Solution B which is an ASP.NET Core 1.1 web application. In it I browse to my local repository (where I have manually copied the NUPKG built by Solution A) and install my SolutionA.MyPackage into the web application. VS.2017 says it was successful at installing it. I see it listed in the project's NuGet dependencies.
However, when I try to use ANY of the objects defined in that NuGet package I get a red highlight saying it is not found as if there was no NuGet or assembly reference to that DLL but there is!
What is causing this Visual Studio generated Nuget package to be installed and yet act as if it has not even been referenced?
UPDATE - CSPROJ TARGET
As for copying to my local repository, I added this to CSPROJ but it was not working (somebody had suggested it as I put it). I finally figured out why it did not work, the ItemGroup must be inside the Task.
<Target Name="CopyPackage" AfterTargets="GenerateNuspec">
<ItemGroup>
<MyPackageFiles Include="bin\Release\PackageId.*.nupkg" />
</ItemGroup>
<Copy SourceFiles="#(MyPackageFiles)" DestinationFolder="D:\My Repository\MyNugget\Publish" />
</Target>
UPDATE NuGet Inspection
I opened the NUPKG with NuGet Package Explorer and it shows this more or less:
content\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
contentFiles\
any\
netcoreapp1.1\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
lib\
netcoreapp1.1 (.NEtCoreApp, Version=v1.1)
MyPackage.dll
UPDATE 3
Since NuGet seems to have stopped working (used to work well earlier) I opted for using an Assembly Reference rather than a NuGet (for now). In this situation something odd happens, when coding I can reference ALL the objects in the referenced assembly (former NuGet) and therefore no compilation errors on the main project BUT when I then run the web application I get an internal error because it says
FileNotFoundException: Could not load file or assembly
'MyPackage, Version=0.0.3.0, Culture=neutral, PublicKeyToken=null'.
The system cannot find the file specified.
Unknown location
Which is strange because in the Solution Explorer I see the assembly reference and when I click on it (main application) I can navigate to all the objects that I have defined in that assembly. Why it cannot find it anymore?
It is working again (as it was before!). Today I could open the solutions but when I tried to download an extension (Tools | Extensions) I got an error message about an Access Denied or something like that. It has happened before since I installed to VS.2017.
Of all the Visual Studios I have used since 2002 this has been the most unstable! (and I have update 15.2).
When I saw this error happening again I knew how to get rid of it and thought, "hey, maybe that is what is keeping the NuGet package to be installed but not found or the problem with a direct assembly reference".
So I went to my C:\Users\AppData\USER\Local\Microsoft\VisualStudio\15.2* folder and removed it completely.
After that I the ACCESS DENIED issue went away with the side effect that I had to reinstall all extensions again. I attempted again to install my own NuGet, it did so successfully and as expected (was not happening during the long glitch) the objects were found and the web application worked again.
So our company has a local Nuget repo that we use for our solution. In our NuGet.config file, we add the package sources as such
<packageSources>
<add key="xxxxxx" value="\\tfs.xxxxxx.com\xxxxxxNuget" />
<add key="Nuget Cache" value="\\tfs.xxxxxx.com\NugetCache" />
</packageSources>
When we restore packages on a PC with Visual Studio, this works fine (I can type the address into the windows Explorer, and it finds it).
Now, with ASP.NET 5 (aka ASP.NET Core - Hanselman - ASP.Net 5 Is Dead) and using Visual Studio Code on the Mac, when I run the command to restore packages, I get an error stating that the local package source doesn't exist.
My guess is that this is due to how file systems navigate network drives. But I can't figure out how to get this config to work such that I can restore the packages...
Any ideas on how to access the local (local meaning on the network) repository?
Answer, you can't right now with what NuGet supports. Work around is to use the /Volumes drive after mounting the location with smb.
Only trouble is that you're going to need to make sure the drive is mounted when you try and restore packages, it won't happen automatically.
I have installed the Oracle Client for the 64 bit machine using the XCopy 11.2 provided by Oracle (Installed everything as per the read me instructions).
I am using Visual Studio 2010 and the project is of type ASP.NET Website.
When I tried to execute my ASP.NET Website using the Oracle Connection installed above..it is giving me the error from the web.config file during compile time.
**
"Could not load file or assembly
'Oracle.DataAccess, Version=4.112.2.0,
Culture=neutral,
PublicKeyToken=89b483f429c47342' or
one of its dependencies. The system
cannot find the file specified"
**
It worked if I changed the value of Enable 32-Bit Applications to True in IIS App pool.
But my requirement is to make it work on 64 bit machine with 64 bit ODP.NET connector, So I do not want to change the value of Enable 32-Bit Applications to True.
So, If you could please help me finding an answer that would be greatly appreciated. Please help me fixing the above error.
The best possibility to handle this is to use the x86 version locally with Visual Studio and x64 version on the server with IIS.
To do this you have to download both versions - copy one in folder lib\x86 and the other in lib\x64
After this you have to modify the project file(s) - visual studio supports conditional references. Add following section to your project file:
<PropertyGroup>
<ReferencesPath Condition=" '$(Platform)' == 'x86' ">..\Lib\x86</ReferencesPath>
<ReferencesPath Condition=" '$(Platform)' == 'x64' ">..\Lib\x64</ReferencesPath>
</PropertyGroup>
After this reference the odp.net assmebly like this:
<Reference ... processorArchitecture=$(Platform)">
<SpecificVersion>False</SpecificVersion>
<HintPath>$(ReferencesPath)\Oracle.DataAccess.dll</HintPath>
<Private>True</Private>
</Reference>
This way when you can build locally as x86 and on the server x64 and always the correct version of Oracle.DataAccess.dll will be referenced.
Alternatively if you only want to use the x64 version than you have to stick to IIS even you work locally OR you could try to run the open source version of Cassini in x64 mode (http://cassinidev.codeplex.com).
For me the best possibility is to reference both versions as described above - this has been working fine for everyone on my team for a while now.
You must install 64-bit Oracle Data Access Components (ODAC) since the Oracle Client Installation doesn't register Oracle.DataAccess.dll into the assembly.
If your oracle data access installation is OK, everything should work after unchecking "Enable 32 bit applications" in your Application Pool settings.
If you still have the same error, it is possible that you have a 32 bit dll in your bin folder of the website. Just delete it and the website will use the 64 bit from the assembly and it should work.