Samples can't be complied, CLR forms can't be viewed in designer

Jul 28, 2015 at 12:59 PM
samples from 1.0.22.3
WixSharp Managed Setup - Custom Dialog
I cannot compile your samples on VS2013. It cannot resolve references.
What attempts to fix was made:
  1. Added project to an empty solution
  2. Restore Nuget packages
  3. Reinstall Nuget packages
    The error is Error This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\WixSharp.1.0.22.3\build\WixSharp.targets. D:\MyWorking\SjPdf_Installer\WixSharp.1.0.22.3\Templates\ProjectTemplates\WixSharp Managed Setup - Custom Dialog\WixSharp Setup.csproj 87 WixSharp Setup
Coordinator
Jul 28, 2015 at 1:10 PM
I just tested it again on VS2013 and I see no problems.

Though it may related to the way VS templates with preinstalled NuGet packages work.

But before we continue can you please just test if you can download the NuGet package correctly.

In a clean ConsoleApplication project, in the Package Manager Console execute "Install-Package WixSharp". After that can you verify that you have now references to WixSharp.dll and WixSharp.UI.dll and both are of the v1.0.22.3?
Jul 28, 2015 at 2:11 PM
Verified, it's ok
Coordinator
Jul 29, 2015 at 3:54 AM
Edited Jul 29, 2015 at 4:38 AM
After various experiments on multiple PCs it became evident that the Project Templates with the NuGet package configuration embedded don't perform package restoring reliably.

Thus the packages.config has been removed and now user is required to execute "Install-Package WixSharp" manually. The problem and the solution described here.

The VS extension has also been updated.
Jul 29, 2015 at 12:15 PM
Edited Jul 29, 2015 at 12:17 PM
"Install-Package WixSharp" manually doesn't help
http://screencast.com/t/hQwYKb1EV
Coordinator
Jul 29, 2015 at 12:24 PM
The image didn't go through.

When you push the image can you also attach the *.csproj file just after you created the project from template but before you executed "Install-Package WixSharp".

With the new templates the situation is much simpler. The template file is just a plain-vanilla C# project and NuGet package is added manually. You already confirmed that NuGet package works in a _HelloWorld _ project so it must be something wrong with the project file created from the template. Quite possibly the VS is still using the old template. The new templates don't have packages.config file included.
Coordinator
Jul 29, 2015 at 12:28 PM
OK. I see. Judging from the image you are still using old templates. If it is a new template there should be no "restoring" but installing only.

You will need to ensure that the old templates are removed. If you install them manually delete them and also (for VS2015) clear the template cache. After you are done. Restart the VS and and install the templates from the extension manager.
Jul 29, 2015 at 5:02 PM
it's new templates (I copied them locally and just try to open in VS2013, I don't have VS2015: ... WixSharp.1.0.22.3\Templates\ProjectTemplates\WixSharp Managed Setup - Cusom UI)

Old templates placed in other folder, how can they influence?
Jul 29, 2015 at 6:00 PM
I fixed it!

In the project files and in repository path to packages were changed from "..\packages......" to "packages" as actually it placed in the same directory. So finally I can see the forms.

Another problem appears on build server where also the problem with references appeared:
setup.cs (6): The type or namespace name 'WixSharp' could not be found (are you missing a using directive or an assembly reference?)

I see by logs that it installs nuget package.

P.S. there is no possibility to install packages manually on build server
Coordinator
Jul 30, 2015 at 1:58 AM
OK. Great.
A few comments that may help you to avoid the same problems in future...
  • I copied them (templates) locally and just try to open in VS2013....
    Not a good idea. Templates should be properly deployed to allow the actual integration with VS. Otherwise the opened project correctness is compromised and every other problem you observed is most likely a result of this initial mistake.
  • 'WixSharp' could not be found... I see by logs that it installs nuget package.
    It is a missing ref assembly problem. The package may be installed but the project may not necessarily reference it correctly. The best way to verify it is to expand the refassemblies tree in the VS Solution Explorer and verify that the WixSharp assemblies are resolved.
  • ...path to packages were changed from "..\packages......" to "packages"...
    Normally "..\packages" is created by nuget.exe and it verifies that the path is valid. Thus fully removing the package (not only the folder) and installing the package again should ensure the validity of the project paths. But in your case (see comment #1) it all becomes questionable.
  • ...install packages manually on build server...
    Of course.
    You can install package with nuget from VS package manager on the build PC. Though if your are trying to do this with raw MSBuild then it is a bit tricky. I found that it almost never works well with package restoring.
    And you can just forget about nuget and add WixSharp assemblies manually, the old fashion way. It's just two assembly files: WixSharp.dll and WixSharp.UI.dll
Jul 30, 2015 at 9:48 AM
I think there is some misunderstanding:
I copied them (templates) locally and just try to open in VS2013....
Not a good idea. Templates should be properly deployed to allow the actual integration with VS. Otherwise the opened project correctness is compromised and every other problem you observed is most likely a result of this initial mistake.
  • I used file readme.txt as an instruction for installation. Is this enough? or what do you mean by "properly deployed"?
  • Also I couldn't do anything with project because they are supplied without solutions. I have to make solution and save it in order to make manipulations .
    "The best way to verify it is to expand the refassemblies tree in the VS Solution Explorer and verify that the WixSharp assemblies are resolved."
  • of course I looked to references and there were no any usefull info, just indicated that they all couldn't be resolved, but after fixing nuget paths all references were resolved
I also fixed the problem with nuget packages on build server. Packages were actually restored but then couldn't be found.
Similar story. For some reason the paths looked like "...WixSharp.bin.1.0.22.3\lib..." instead of "...WixSharp.1.0.22.3\lib..."


The main my question about build server: if nuget package is installed and build is successful and wix is installed on build server is this enough for .msi file been created?
Coordinator
Jul 30, 2015 at 11:54 AM
Edited Jul 30, 2015 at 12:53 PM
It doesn't make much sense to investigate any further further why nuget.exe didn't injected correct path into the project file when restoring was triggered. I am sure there was some reason but ... the latest templates have no NuGet integration at all so it becomes kind of irrelevant. Now it will be completely up to you to implement deploying the project dependencies.
"if nuget package is installed and build is successful and wix is installed on build server is this enough for .msi file been created?"
I would put it differently: Yes. If you have WixSharp.dll, WixSharp.UI.dll and WiX installed it is sufficient for building .msi file.

But the way how you get the dll files (as nuget package or as manual copies) is irrelevant. That is why I don't want to name "package" as a pre-condition.
Jul 30, 2015 at 2:05 PM
Thank you for clarification.

So than of course I have to refuse to use nuget as well

The problem: _on build server it builds successfully but in the end it doesn't create .msi file.
As far as I know wix is installed on build server but I'm not completely sure because I don't have access to it, and I don't know the version installed.

so some questions:
  1. Can it be build using "ANY CPU, x64" ?
  2. What other problem can be if suppose that wix installed on build server
Coordinator
Jul 30, 2015 at 2:41 PM
Since you are not using NuGet that would adjust the post-build action for you you have to do it by yourself by adding a proper post-build event action to th eproject. You can do this as it is described in the tutorial. Without this step the msi will not be created.

As fro WiX, if it is installed in the default location then the "builder" (your executable) will find it automatically if not then you will need to set the environment variable WIXSHARP_WIXDIR to the location of WiX or to do it from code with WixSharp.Compiler.WixLocation. But most likely you will not need to do this.
Jul 30, 2015 at 5:08 PM
  1. Our admin refused to install (deploy) wix# on build as there is no automatic updates
  2. We use msbuild on our build server for building? So what is the instruction for this?
Coordinator
Jul 31, 2015 at 1:50 AM
Edited Jul 31, 2015 at 1:54 AM
"So what is the instruction for this?"
Sack your admin. :)

But if seriously, I can no longer help you. If you have policies that prevent you from using COTS (DLLs in this case) then the problem is well beyond of the Wix# scope and you need to talk to someone in your team.

Saying that I am very surprised about "as there is no automatic updates" interpretation. There is an update mechanism. You can use nuget as everyone else.You have confirmed that nuget works for you on your workstation but you just cannot implement the process on the build server (no wander as you have no control over it). So it is the problem with the build server arrangement but not with the product you want to use. You will need to sort it out within your team.

The 'automatic' part in "as there is no automatic updates" quote puzzled me even more. Why anyone would even want it to be automatic. Imagine scenario when you have your product released and msi built. You decided to make a cosmetic change (e.g. label text change) and you rebuilt the whole solution. During the build it auto-updates wix# assemblies, which now contain just freshly introduced defect (it happens). But you are not going to retest deployment as the change was only in the label. Why would you allow anything to make changes to your codebase (yes Wix# assemblies are part of your code base) without your knowledge.

You can still easily overcome your restrictive build server policies. You can just put these two WixSharp dlls under your source control and you are done. This is your controlled semi-automated update. But it looks like you have much bigger problem then just Wix# usage.

Good luck