Currently my application is running in .net framework and .net standard 2.0 which is works fine and all the artifacts(packages) are getting installed correctly , due to some requirement we have migrated one project into .net 6 windows after that the artifacts are not getting install. it shows the log message as fails to install .
Wix setup for .net framework and .net standatd application
<Component Id="AdminService_Logic_dll" Guid="{2677C0B4-1560-8CD9-568C-6097FF926C3A}">
<File Id="AdminService_Logic_dll" Name="AdminService.Logic.dll" KeyPath="yes" Assembly=".net" AssemblyManifest="AdminService_Logic_dll" AssemblyApplication="AdminService_Logic_dll" DiskId="1" Source="$(var.SourceDir)\AdminService.Logic.dll" />
</Component>
Wix setup for .net net6.0-windows application
<Component Id="TestCase_exe" Guid="{0D8D84F1-FFC5-28F6-F1D7-8620DA17313B}">
<File Id="TestCase_exe" Name="TestCase.exe" KeyPath="yes" DiskId="1" Source="$(var.SourceDir)\TestCase.exe" />
</Component>
since .net 6 doesn't support AssemblyManifest, Assembly attribute we have removed . currently my wix project's ProductVersion is 3.10 .
could you please guide me where the setup has wrong so that the artifacts (packages) are not getting install after migrate one application into .net 6
Related
Currently In my Solution it is containing .net Framework 4.8 , .net Standard and net 6 assemblies .
during installing the particular artifacts (.exe) of the solution, I can't install it and getting the exception as
Error 1001. Unable to get installer types in the <file>\service.exe assembly.--> Unable to loadone or more request types.
for other .net framework and .net standard the wix setup are like this
<Component Id="__Device_dll" Guid="{9C75189F-BE83-4227-A798-F00C76F27CE6}">
<File Id="__Device_dll" Name="Device.dll" KeyPath="yes" Assembly=".net" AssemblyManifest="_Device_dll" AssemblyApplication="Device_dll" DiskId="1" Source="$(var.SourceDir)\Device.dll" />
</Component>
but for .net 6
<Component Id="Process_Executor_exe" Guid="{0D8D84F1-FFC5-28F6-F1D7-8620DA17313B}">
<File Id="Process_Executor_exe" Name="SProcess.Executor.exe" Source="$(var.SimulationSourceDir)\Process.Executor.exe" />
</Component>
Is something I am missing in wix set up ,because the application rus fine in visual studio , during installation only Error 0x80070643: Failed to install MSI package these error logs are comming.
Code snip:
<Component Id ="zyx" Guid="{4820d7d5-30a0-448c-a80e-83609c92f235}">
<File Id="DLLGAC" Assembly=".net" KeyPath="yes" Source="folder\pqr.xyz.dll"/>
</Component>
I'm trying to upgrade older version of assembly using above code but getting error
skipping installation of assembly component: {4820d7d5-30a0-448c-a80e-83609c92f235} since the assembly already exists
From my experience version of your library must be higher than installed library. And there's no option to copy with overwrite. So if library is yours - change version of library to higher.
If not:
In my case someone added to installer modified 3rd party with some higher version and it was impossible to replace it with official new version. Only way to solve it was custom action with simple File.Copy with overwrite.
How to create custom actions
<Component Id="zyx" Guid="{BB23E1A4-9270-41AA-9266-4D15506E1C63}" Win64="yes">
<File Id="DLLGAC" Source="folder\pqr.xyz.dlll" KeyPath="yes" Assembly=".net"/>
</Component>
After changing the code format it's working which is strange but it works :)
What is the method to create a web application nuget package with TeamCity?
I'm totally confused after .NET became a thing.
What I'm attempting to do, is to create a nuget package with a .Net Framework 4.8 webapplication in it.
The ways things worked before, seems to be outdated or deprecated.
In TeamCity, the meta runners that were used previously are either deprecated or not functioning very well.
When I'm googling f.ex. msbuild
https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package-msbuild
I get stuff about .Net Core and .Net Standard, nothing about .Net Framework. And the stuff is often 10 years old or more.
I might have gone stupid after how nuget works in .NET, since everything is tied to projects and you can actually avoid having code shipped (the cs files) with the web application.
The closest I've gotten so far, is by making a comprehensive .nuspec file, then run in the project directory of the web application after the project has been built with all necessary dependencies.
However, the build output will log warnings:
WARNING: NU5100: The assembly 'bin\Antlr3.Runtime.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.
The nuget pack command
nuget pack <path to nuspec file>
The nuspec file:
<?xml version="1.0" encoding="utf-8"?>
<package>
<metadata>
<id>MyPackageId</id>
<version>1.0.0.0</version>
<title>My application title</title>
<authors>my authors</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Some description</description>
<releaseNotes>Summary of changes made in this release of the package.
</releaseNotes>
<copyright>My copyright</copyright>
<tags>framework application</tags>
</metadata>
<files>
<file src="bin\**\*.*" target="bin"/>
<file src="Content\**\*.*" target="Content"/>
<file src="Resources\**\*.*" target="Resources" exclude="**\*.cs"/>
<file src="Scripts\**\*.*" target="Scripts" />
<file src="Views\**\*.*" target="Views" />
<file src ="favicon.ico" target=""/>
<file src ="Global.asax" target=""/>
<file src ="Log4Net.config" target=""/>
<file src ="StrongNameKeyFile.snk" target=""/>
<file src ="Web.config" target=""/>
</files>
</package>
Rather comprehensive ...
I am struggling to install a com based isapi dll globally into iis 7.5 using wix 3.6.3303.1/4.0.12.0.
I have the following wix config (full config here):
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="IsapiDll" Guid="ADD-GUID-HERE">
<File Id="isapidll" Name="isapi.dll" Source="isapi.dll" />
</Component>
<Component Id="IisFilter" Guid="ADD-GUID-HERE">
<CreateFolder />
<iis:WebFilter Id="IisFilter" Name="MyIsapi" Path="[INSTALLFOLDER]isapi.dll" LoadOrder="last" Description="MyIsapi" />
</Component>
</ComponentGroup>
</Fragment>
I receive the following error in my msi log when running on Windows 7 32bit with IIS7.5:
WriteIIS7ConfigChanges: Error 0x8007000e: Failed while finding IAppHostElement filter/#name=(null)
WriteIIS7ConfigChanges: Error 0x8007000e: Failed to delete filter
WriteIIS7ConfigChanges: Error 0x8000ffff: Unexpected IIS Config action specified for global filter
WriteIIS7ConfigChanges: Error 0x8000ffff: Failed to configure IIS filter global.
WriteIIS7ConfigChanges: Error 0x8000ffff: WriteIIS7ConfigChanges Failed.
I fear the problem is a bug in wix itself.
CreateGlobalFilter() passes pwzFilterName to DeleteCollectionElement() before it has been assigned a value. This later causes Iis7FindAppHostElementString() to be called with a null wzAttributeValue value which appears to be the cause of the error.
I could of course be on a wild goose chase and be happy to be pointed in the right direction...
Update:
I've now played with website level installs and have that working with the addition of the WebSite attribute and element. Config here
Edit: Changed path attribute to correct format.
0x8007000e means out of memory and the (null) in the message makes me bet this is a bug in the custom action. If you can debug it that's ideal. In any case, entering a bug at http://wixtoolset.org/bugs would probably be a good idea.
You forgot to add WebSite attribute, this code works well for me in WIX3.7:
<Component Id="IsapiFilterComponent" Guid="AE102719-D7DE-450A-A44C-29E7D9A36C0D" KeyPath="yes">
<iis:WebFilter Id="MyWebDavFilter" Name="MyWebDavFilter" Path="[INSTALLFOLDER]MyWebDavFilter.dll" LoadOrder="last" Description="My Web Dav Filter" WebSite="DefaultWebSite" />
</Component>
but this
<Component Id="IsapiFilterComponent" Guid="AE102719-D7DE-450A-A44C-29E7D9A36C0D" KeyPath="yes">
<iis:WebFilter Id="MyWebDavFilter" Name="MyWebDavFilter" Path="INSTALLFOLDER]MyWebDavFilter.dll" LoadOrder="last" Description="My Web Dav Filter"/>
</Component>
gives the same error you have.
Of course, you have to add <iis:WebSite> element to your wxs file.
I am creating an installer using WiX which contains few dlls. In the original script first gacutil.exe and then regasm for each dll is called. I am having a problem when transfering this idea into WiX. Here is the code fragment for installing into GAC :
<Component Id="GMAG.Core.Serialization.dll" Directory="_2.2.8.0" Guid="{my_guid}">
<File Id="my.dll" Source="my_src" Assembly=".net" KeyPath="yes" Checksum="yes"/>
</Component>
Now the question is how WiX will perform the assembly registration? My problem is:
I can't create another <File Id="my.dll" Source="my_src" KeyPath="yes"/> in the same component cause there must be only one keyPath="yes" attribute/component.
I can't put keyPath="yes" in component level, as it breaks component reference counting system.
I can't create <File Id="my.dll" Source="my_src"/> without keyPath="Yes", as it generates compilation error.
I can't create a seperate component as two components will try to install same file.
I know I don't need to call regasm or regsvr32 when using heat. In the component code :<File Id="my.dll" Source="my_src" KeyPath="yes"/> should be enough for the registration.
I'm using heat and now I'm stuck as I have to do assembly registration also.
Assembly=".net" will put you assembly in the GAC, you will then need registry keys for the COM registration. If you run Heat against your assembly it should generate the code fragment you require.
That's how we register DLL in GAC via WIX 3.5:
<Component Id="Level0GAC" Guid="21735A8C-DD0C-4f4e-8AB5-B5BB8C55726B" DiskId='1'>
<File Id='Level0' Name='DLLFileName.dll' DiskId='1' KeyPath="yes"
Source='DLLFileName.dll'
Checksum="yes" Assembly=".net" AssemblyManifest="Level0">
</File>
</Component>
Indeed, there can be only one file inside a Component with a KeyPath set ot "yes", that's why for several DLLs you should create several Components.