Quantcast
Channel: wixsharp Discussions Rss Feed
Viewing all 1354 articles
Browse latest View live

New Post: third part dll

$
0
0
Hi folks,

The requirements concerning my installer project have been changed. So I have to rebuild the structure of my project folder. I have now four asseblies in separate sub projects. Three (wix sharp)projects serve for building individual msi. Moreover I have now a class library that contains helpful classes including functions I use in some others asseblies. In spite of the fact that I refered the project a exeption error have been appeared.

System.Reflection.TargetInvocationException: ... ---> System.IO.FileNotFoundException: ... InstallTools.dll ...

Therefore I modified the class library to contain a Wix Extension Class (concerning to http://wixtoolset.org/documentation/manual/v3/wixdev/extensions/extension_development_simple_example.html"). All the other classes inside the library use this class as a base class. The elementary construktor is private. Could it be a problem? Finaly, I have added a reference to the "wix sharp"-projects: project.WixExtensions.Add(@"Folder\InstallTools.dll"). Unfortunately, it doesn't helps. Frown | :( How can I work with separate asseblies concerning to building msi with wix sharp?

Cheers!
Olga

New Post: session properties and subfolders

$
0
0
Hi folks,

Stepping out your "AdminInstall" project I would like to copy some files and set some shortcuts to a special folders.

I have defined several "Dir" objects in my project.

new Dir(@"[INSTALLDIR]",

new WixSharp.File(binaries, @"AppFiles\ConverterGUI.dll"), new WixSharp.File(binaries, @"AppFiles\ConverterLib.dll"), new WixSharp.File(binaries, @"AppFiles\ConverterInterlink.dll") new Dir(@"[DOCUPATH]", new WixSharp.File(docs, @"AppFiles\HandbuchGMC-Konverter.pdf")), new Dir(@"[DATABASEDIR]Formatkonverter", new WixSharp.File(database, @"AppFiles\ConfigurationDatabase.mdb")), new Dir(@"[MWSC]GMC Konverter",
new ExeFileShortcut(binaries, "Messwertverwaltung", "[INSTALLDIR]Messwertverwaltung.exe", " ")),

"MWSC", "DOCUPATH" and "DATABASEDIR" are properties I predefined in my Main method (project.Properties = new[]
{
new Property("DATABASEDIR", @"C:\Qmax\Server\QmDocDir"),
new Property("STARTDIR", @"C:\Qmax"),
new Property("LOGPATH", @"%ProgramData%\GMC Systems\Konverter\Log\"),
new Property("MWSC", "LEER"),
new Property("DOCUPATH", @"%ProgramData%\GMC Systems\Konverter\Doku\"),
new Property("WINOS", "LEER"),
};
)
and set in a custom action via session["property name"]="valid string"

TARGETDIR is assigned to "e:". Wix sharp produce a Property named TARGETDIR._MWSC_GMC_Konverter and set it to e:[MWSC]GMC Konverter\ and copy the data to this folder etc.

How can I access my session property? Please ask me what I misobeyed.

Moreover I have to add some resource files. Some of this files are in folders with several subfolders.

Here is what I tried:

new Dir(@"[CommonAppDataFolder]GMC Systems\Konverter\",
new Dir(NetSRCXP, "WIN_XP_VISTA_SERVER2003_SERVER2008_NET", new DirFiles(NetSRCXP, @"AppFiles\WIN_XP_VISTA_SERVER2003_SERVER2008_NET*.")), new Dir(NetSRC8, "WIN81NET", new DirFiles(NetSRC8, @"AppFiles\WIN8NET*.")), new Dir(NetSRC81, "WIN8NET", new DirFiles(NetSRC81, @"AppFiles\WIN81NET*.*"))) Using DirFiles failed? How can I take all files from all subfolders?

Many thanks in advance!
Olga

New Post: InstalledFileAction exiting with an error leaves MSI application in Control Panel

$
0
0
I do have a solution for you, but I really want to discourage you from using it. :)

Solution:
  • Add your ntrights.exe to your project as Binary not as File
  • Have your managed custom action executed during both install and repair. You can have it at any step. Even Before InstallInitialize.
  • In the managed CA extract ntrights.exe from MSI int a temp dir, run and delete it.
Have a look at 'Simplified Bootstrapper' sample. It does exactly that.

Architectural considerations:
Your all problems (in fact everything described in this thread) are caused by the fact that you are trying to push your setup to do something that it's not design to do - Configuration.
Do you remember the fundamental design principle "Separation of concerns"? Apply it to your problem. Setup (any setup) is concerned about deploying of the files. Full stop. Configuration is not part of the setup but a part of the application initialization stage. That is why MS introduced a great deployment guideline (as part of the Vista application certification). This guideline requires the applications to configure the user profile on the first start of the installed application but not at the installation. The benefits are enormous:
  • No need to have a complicated setup UI as no need to interact with the user after the last file is deployed. The user interaction is delegated to the application executable. You can still start the app (in config mode) at the last step of the installation.
  • Simple path for reconfiguration of the application. Start it at any time in the config mode without resorting to the "Repair", which effectively installs the product again for no real reason.
  • App upgrade is incredibly simple. Upgrade binaries and the app itself will pick the prev app settings if present.
  • Licencing, target system validation all becomes very straight forward.
  • ...
The deployment solution designed this way becomes something that I would call a "Lean Setup". The latest Wix# dev effort is going towards this direction.

If you agree with this concept than you can completely remove your ntrights.exe form the setup and embed it as a resource in your app. And on the first start extract ntrights.exe in the temp folder, run...... you know the drill.

Good luck.

New Post: How to install prerequisites like .net framework for WPF External UI

$
0
0
How to install prerequisites like .net framework for WPF External UI. Because without .net framework we can't run WPF Exe. Examples please thanks in advance.

New Post: session properties and subfolders

$
0
0
How can I access my session property?

the same was as you assigned it:
string value = session["property name"];
DirFiles failed? How can I take all files from all subfolders?
You need to use "Files" class . Have a look at Release Folder sample.

A few notes.
It is better not to use square brackets in the explicit IDs (e.g. 'new Dir(@"[INSTALLDIR]"') as these brackets have special meaning for MSI/WiX. In fact you can skip , INSTALLDIR at all as it will be auto generated for you.
Also keep in mind that if you preserve wxs file with Compiler.PreserveTempFiles = true; you can troubleshoot your setup more effectively.

New Post: How to install prerequisites like .net framework for WPF External UI

$
0
0
You need to create a simple native bootstrapper that need to check if you WPF exe is compatible with the target OS. Of course if your target system is a modern version of Windoes you are fine. .NET is garanteed to be there and you can use even a managed bootstrapper:
staticvoid Main()
{
    if(!CanRunWPF())
    {
        MessageBox.Show("Pleas install .NET form this URL....") ;
    }
    else
    {
        var wpfExe = GetResource("setup.exe");
        Process.Start(wpfExe);
    }
}

New Post: third part dll

$
0
0
It is hard to understand what is going on there by having your description only.
but it may be much easier for you to troubleshoot if you execute Compiler.BuildMsiCmd. This way you will see (in the produced batch file) how your extension assembly is passed into candle/light and what may be a problem. Though I don't see any reason why you need to create an extension if you can do the same (managed CA) directly in your build script. See the whole set of "DTF (ManagedCA)" samples.

New Post: session properties and subfolders

$
0
0
Oleg,

I would like to access my session property in the main method. The problem is that session object doesn't exists in the main method.

New Post: InstalledFileAction exiting with an error leaves MSI application in Control Panel

$
0
0
Thanks Oleg, but I would rather use the native/built-in MSI repair functionality so it works with all my deployed files, not just the "ntrights.exe" file.

About the suggestion to execute the managed custom action during both install and repair before InstallInitialize, this is not working because the files are not copied yet at this stage... unless I'm doing it incorrectly? This is the action that I use:

new ManagedAction("MySetupExeAction", "MyExternalDll.dll", Return.check, When.Before, Step.InstallInitialize, Condition.NOT_BeingRemoved, Sequence.InstallExecuteSequence);

If I change the above to use Step.InstallExecute, the action is executed normally.

I guess I'll keep looking for a solution to address the repairs. Incidentally, I have also tried:
        Compiler.WixSourceGenerated += document =>
                                       document.Descendants("File")
                                               .ForEach(e => e.SetAttributeValue("KeyPath", "yes"));
and:
        WixSharp.Property reinstallMode = new Property("REINSTALLMODE", "vamus");
        properties.Add(reinstallMode);
and using:
MsiExec.exe /fvamus "{xxxxxxxxxxxxxxxxxxxxx}" /quiet /norestart /l*vx ".\Test repair.log"

...but repairs still do not work.
My custom action executable does get called, but is failing because the "ntrights.exe" is not re-extracted by the MSI.

I'll let you know if I find a solution to this. Likewise if you know... :)

New Post: Custom managed action creates files in SourceBaseDir

$
0
0
I have a custom managed action that works (yeah!), but it is creating 2 additional files in the Project.SourceBaseDir and in the install directory:
  • CustomAction.config
  • MyExternalDll.CA.dll
Is it normal?

New Post: InstalledFileAction exiting with an error leaves MSI application in Control Panel

$
0
0
...but I would rather use the native/built-in MSI repair functionality so it works with all my deployed files, not just the "ntrights.exe" file.
I expected this answer :)
This is exactly the problem. Repair means 'redeploy' and your ntrights.exe has nothing to do with the deployment (I guess it is some kind of OS user right configuration). Thus you cannot reconfigure/update the user rights unless you reinstall the all files. This is the reason you never configure user account as part of the email client installation. You can auto-start the "add account" wizard after the install but you never do the actual account configuration from the install/repair activity.

If you try to get your application "certified for Windows Vista+" you would have real problems because of the deployment strategy you chosen.

Anyway, enough of this. This discussion is purely theoretical. You will choose the approach you think is the most appropriate for the situation. :)

... this is not working because the files are not copied yet at this stage...
Why? I suggested "Add your ntrights.exe to your project as Binary not as File". Meaning it is never-ever going to be installed. "In the managed CA extract ntrights.exe from MSI" means you need to extract the file from the database (msi) not to find it among installed files. 'Simplified Bootstrapper' sample does exactly that. It shows how execute the file which is embedded into msi but is not destined to be installed.

New Post: Custom managed action creates files in SourceBaseDir

$
0
0
Yes it is. These are the temp files you most likely decided to keep with:
Compiler.PreserveTempFiles = true;
The files themselves are the native dll and the config file implementing your custom actions

New Post: session properties and subfolders

$
0
0
The 'main' method is the entry point of your setup build script. It is executed when you build your MSI and never else. When you execute your MSI the only your code that can be invoked is your custom action and it has session argument. So you need to do what ever you are trying to do in the custom action code.

New Post: Search over target machine registry

$
0
0
Is it possible to search over target machine registry with WixSharp?

Something like that in Wix
<Property Id="IEVERSION">
    <RegistrySearch Id="IEVer"
                    Root="HKLM"
                    Key="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer"
             Name="svcVersion"
                    Type="raw" />
</Property>

New Post: Search over target machine registry

$
0
0
Yes it is possible. Have a look at "RegistrySearch" sample.

New Post: .net 4.5 prerequisite is not working properly (Wix# 1.0.16.0, WixTools 3.9)

$
0
0
When I have enabled .net 4.5 framework prerequisite and test - my installer says than I should install .net 4.5. But I have installed .Net 4.5 framework on my machine.

I have doublechecked it with simple utility named ".NET Framework verification tool" by Aaron Stebner (Microsoft), his article and app link.

Probably it's not Wix#'s fault. Because .Net 4.0 prereq works well.

New Post: WixSharp.File and System.IO.File, WixSharp.Assembly and System.Reflection.Assembly naming convention

$
0
0
There is a thing which bothers me a bit. WixSharp.File class.

When I need to use WixSharp.File & System.IO.File types in the same code block I need to use full names of both types or use following trick:
using System.IO;
using WixSharp;
using WixFile = WixSharp.File;
using File = System.IO.File;
This way I can use File declaration as System.IO.File and WixFile declaration as WixSharp.File.

But then if I need to copy and paste my code to another project - it asks me to resolve declarations. And I can't just cope and paste. I need to make additional code and paste of my workaround with "using". More than one - when I need to share my code with another developer - they need to have this workaround to. But they can have another workaround with different namings of mentioned types.

So I would like to discuss renaming of WixSharp.File class. I propose WixFile.

There is another type named WixSharp.Assembly and crossed with System.Reflection.Assembly.

Yes, we can use the same workaround but I think it's not a good idea. I propose WixAssembly name instead of WixSharp.Assembly.

I think both propositions are not redundant in names and more clear for code-reading.

Dear community, please let me know your feedback.

New Post: .net 4.5 prerequisite is not working properly (Wix# 1.0.16.0, WixTools 3.9)

$
0
0
I think I may just know the reason.

MSI is really inconsistent with the names and the values for the ".NET presence" properties.
For example for .NET4.0 the property value is expected to be "#1" and for .NET4.5 it has to be "1".

I had to change the semantics of SetNetFxPrerequisite. Now it takes a condition string instead of the property name:
project.SetNetFxPrerequisite("NETFRAMEWORK20='#1'", "Please install .NET 2.0 first.");
project.SetNetFxPrerequisite("NETFRAMEWORK30_SP_LEVEL and NOT NETFRAMEWORK30_SP_LEVEL='#0'", "Please install .NET 2.0 first.");

New Post: WixSharp.File and System.IO.File, WixSharp.Assembly and System.Reflection.Assembly naming convention

$
0
0
I fully support the request.
I am not so crazy WixSharp.WixFile. Particularly because it was already commented by users as to "noisy" (at early stage of Wix# development). And also it will be a bit inconsistent with the rest of the Wix# types. However I am completely opened for suggestions.

Just some other ideas:
WixSharp.WixFile -> WixSharp.WFile
WixSharp.WixAssembly -> WixSharp.WAssembly

New Post: WixSharp.File and System.IO.File, WixSharp.Assembly and System.Reflection.Assembly naming convention

$
0
0
May be it sounds "noisy" in case of using with full name declaration.

In another case: WixFile, WixAssembly - clear and intuitive.

WFile, WAssembly - not so intuitive on my mind.

Dear community, please send us your feedback and ideas!
Viewing all 1354 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>