Questions about DaxStudio V2

Dec 8, 2014 at 12:55 PM
Edited Dec 8, 2014 at 1:02 PM
Do I need to uninstall the older version first? I had some problems today with this.

It installs but it doesn't run. I'm using Win7 64bit and it installs into the new app section and then moves to permanent spot when I click it but it doesn't run. Maybe I need to restart my machine.

http://1drv.ms/1CYVO9F
Dec 8, 2014 at 9:35 PM
I have the same problem. Have tried DaxStudio_2_0_0_15_setup on 2 different Win 8 64 bit pc's, and have uninstalled the previous version of DAX before installing the new version.

When I double click on the DAX shortcut I see it momentarily appear in the background processes in Task Manager, then it disappears.
Dec 8, 2014 at 9:46 PM
Edited Dec 8, 2014 at 9:47 PM
I uninstalled all versions. I think the problem is the installer, it uses the same folder "Dax Studio." It should be named something different. I'm going to try this one more time. Uninstall it, reboot, rename the installation folder and then try to run it.
Coordinator
Dec 9, 2014 at 5:20 AM
It's not a bad idea to uninstall the old version first. But you should not need to. The v2 installer actually looks for v1.2 and if it finds it - it should attempt to invoke the uninstaller. So if you are seeing both versions still installed after installing v2 then something has gone wrong and the best approach is to manually uninstall both versions and then re-install v2 (maybe re-booting before re-installing v2, but the installer does not update any system files, so this should not be necessary)

Before building the step that invokes the uninstaller I also just tested just overwriting a v1 install and that worked too. I chose to include the call to the v1 uninstaller as that cleans up a few files that are no longer used. I have a suite of test VMs both Windows 7 & 8, 32 & 64 bit and Excel 2010 & 2013 as well as 10-15 "alpha" testers, so I've tested the installer as much as possible.

For the standalone version the installer is really only needed to make sure the dependencies are present - otherwise it just copies the DaxStudio files to your hard drive. The only registry keys it touches are the ones to register the Excel add-in.

@TonyGaul - in the folder where DaxStudio is installed there is a file called "DaxStudio.exe.config" at the top of that file are some serilog settings which are commented out (surrounded by <!-- -->) If you remove the xml comment and change the path setting to point to a folder on your system (it's currently set to point to d:\temp) then hopefully it should generate a trace file in that location and capture any exception that is getting thrown. If you can post the error message here or click on my name and contact me offline and I can let you know how to email me the log file.

@Residentx10 - if the re-install after the reboot does not work let me know this may be tricky to resolve as it possibly mean that one of the dependencies has not been found. I can probably put together a powershell script or something that will print out the versions for the dependencies. If you are not seeing the DaxStudio logo flash up then enabling the logging is worth a try, but may not help as it sounds like it might be failing before the logging gets initialized.
Coordinator
Dec 9, 2014 at 7:44 AM
In order to manually check the dependencies you can paste the following code into the Powershell ISE and run it
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -recurse |
Get-ItemProperty -name Version -EA 0 |
Where { $_.PSChildName -match '^(?!S)\p{L}'} |
Select PSChildName, Version

$assAdomd = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices.adomdclient")
$assAdomd | select fullname, GlobalAssemblyCache  | format-list

$assAmo = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices")
$assAmo |  select fullname, GlobalAssemblyCache  | format-list
What I would expect to see from this is something like the following:
PSChildName                                                   Version                                                     
-----------                                                   -------                                                     
v2.0.50727                                                    2.0.50727.4927                                              
v3.0                                                          3.0.30729.4926                                              
Windows Communication Foundation                              3.0.4506.4926                                               
Windows Presentation Foundation                               3.0.6920.4902                                               
v3.5                                                          3.5.30729.4926                                              
Client                                                        4.5.51641                                                   
Full                                                          4.5.51641                                                   
Client                                                        4.0.0.0                                                     


FullName            : Microsoft.AnalysisServices.adomdclient, Version=11.0.0.0, Culture=neutral, 
                      PublicKeyToken=89845dcd8080cc91
GlobalAssemblyCache : True


FullName            : Microsoft.AnalysisServices, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91
GlobalAssemblyCache : True
The key information here is that the top section (which lists the .Net Framework version on the PC) should have one of the v4.5 versions and the two assemblies in the bottom section should have version numbers of at least 11.0.0.0
Dec 9, 2014 at 3:55 PM
Hi Darren,

Getting the same issue as @TonyGaul, believe I'm on the latest .net framework, installation seems to work perfectly but literally nothing happens on attempting to open the application.

PS C:\Windows\system32> Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -recurse |
Get-ItemProperty -name Version -EA 0 |
Where { $_.PSChildName -match '^(?!S)\p{L}'} |
Select PSChildName, Version

$assAdomd = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices.adomdclient")
$assAdomd | select fullname, GlobalAssemblyCache | format-list

$assAmo = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices")
$assAmo | select fullname, GlobalAssemblyCache | format-list

PSChildName Version

v2.0.50727 2.0.50727.5420
v3.0 3.0.30729.5420
Windows Communication Foundation 3.0.4506.5420
Windows Presentation Foundation 3.0.6920.5011
v3.5 3.5.30729.5420
Client 4.5.51209
Full 4.5.51209
Client 4.0.0.0
The object of type "Microsoft.PowerShell.Commands.Internal.Format.FormatStartData" is not valid or not in the correct sequence. This is likely caused by a user-specified "format-list" command which is conflicting with the default formatting.
+ CategoryInfo          : InvalidData: (:) [out-lineoutput], InvalidOperationException
+ FullyQualifiedErrorId : ConsoleLineOutputOutOfSequencePacket,Microsoft.PowerShell.Commands.OutLineOutputCommand
Dec 9, 2014 at 4:23 PM
My method didn't. I can't spend anymore time on this. Sorry...
Coordinator
Dec 9, 2014 at 6:48 PM
@AlexR1983 - your output has the .Net framework 4.5, but the error at the end suggests that the AMO and ADOMD dependencies are not installed. This may have been an issue with connectivity at the time of install or problems with a proxy server or something like that. There are instructions and links to the dependencies on the installer wiki page. Try downloading and installing the AMO and ADOMD installers and see if that fixes the issue (there should not be any need to reboot or even re-install Dax Studio, once the dependencies are present it should just start working)

@Residentx10 - no worries, I'm assuming when you say "My method didn't" that you mean that you did not get the expected output from the powershell script. So if you ever do get some time to try this at a later date you could try manually installing the 3 dependencies from the links on the installer wiki page.
Dec 9, 2014 at 7:29 PM
Same issue for me. Stand alone just launches than quits. Addin just... does nothing. Opened an issue for it.

I'll see about modifying .exe.config to grab some logs...
Dec 9, 2014 at 7:40 PM
Logging didn't dump anything. However,...
manually installed: ENU\x64\SQL_AS_ADOMD.msi : no help.
manually installed: ENU\x64\SQL_AS_AMO.msi : working now! (hurray!)

Looks like an issue w/ the installer and dependencies...
Coordinator
Dec 9, 2014 at 7:55 PM
@scottsen - try running the powershell script I posted above. An immediate shutdown is most likely a missing dependency. That looks like it's the issue with AlexR1983 and @TonyGaul sent me more details via email and he actually has v12 of the AMO and ADOMD assemblies which should work (as they are backward compatible with v11), but I'm going to double check that today.
Dec 9, 2014 at 8:16 PM
Edited Dec 10, 2014 at 12:55 PM
I was looking at the dependencies referenced. I'm running SQL2014. I just removed all the SQL12 stuff last month. Do you think that might be the problem?

For SQL 14 user, go here to the Feature Pack, http://www.microsoft.com/en-au/download/details.aspx?id=42295
Dec 9, 2014 at 9:37 PM
This is just a follow up, the ADOMD and ADO feature pack installation didn't make the product work for me.
Coordinator
Dec 10, 2014 at 2:44 AM
It looks like the SQL 2014 versions don't get picked up by Dax Studio. The installer correctly detects the 2014 (v12) assemblies are installed and does not download the 2012 (v11) versions, but the program is still looking for the SQL 2012 (v11) version. So it works on machines that have both SQL 2012 and SQL 2014, but not on ones that only have SQL 2014.

I've added an updated 2014 config file to the release page which you just need to download and copy into the folder where daxstudio.exe was installed (overwriting the existing config file). I'll fix the installer so that it does this automatically for the next release, but this should get you guys working in the mean time.
Dec 10, 2014 at 7:25 AM
Hi Darren, the new config file works fine. Thanks for the quick support!
Dec 10, 2014 at 8:30 AM
Brilliant, works perfect. Thanks Darren and huge thanks for the tool, use this literally daily, invaluable.

Cheers
Dec 12, 2014 at 12:22 AM
When do you think you'll fix this? This still isn't working for me. I uninstalled, reinstalled and replaced the file as specified but it still won't start. I do get asked for permission in Excel though. I'll post the image later.
Coordinator
Dec 12, 2014 at 1:33 AM
Cab you try running Excel as Admin to see if that makes a difference? I have one other user that reports that this is the only way they can get Dax Studio to launch inside Excel, but I don't have a way of reproducing this on any other machine, so I don't know what combination of circumstances triggers this behaviour. Are you able to try running Dax Studio standalone? This will help isolate if the issue is the Excel add-in or the core UI.
Dec 12, 2014 at 8:09 PM
Edited Dec 14, 2014 at 2:31 AM
This doesn't work even with Admin. It will not run from Excel or standalone.
Coordinator
Dec 13, 2014 at 6:03 AM
@Residentx10 - I've created a wiki page with instructions on how to turn on the application and startup logging here. If you switch on both of those, then try to start Dax Studio one or both of those logs should hopefully capture what is going on. You can then either create an issue and attach the logs there or click on the dgosbell link next to this post and send me a message and when I reply you can email the logs to me.
Dec 13, 2014 at 3:05 PM
Edited Dec 13, 2014 at 3:06 PM
It's not logging. Here's the code I used.

DaxStudio.exe.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
  <add key="serilog:minimum-level" value="Verbose" />
  <add key="serilog:write-to:RollingFile.pathFormat" value="C:\Temp\DaxLogs\DaxStudio-12132014.txt" />
  <add key="serilog:write-to:RollingFile.retainedFileCountLimit" value="10" />
</appSettings>
<runtime>

FusionLogOn.reg
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogFailures"=dword:00000001
"LogPath"="C:\data\fusion\"" = I don't have a D drive so I changed this to C Drive


FusionLogOff.reg
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogFailures"=dword:00000000
Dec 13, 2014 at 3:31 PM
Can you tell me what Version of Visual Studio your using?
Coordinator
Dec 13, 2014 at 7:17 PM
I'm using VS2013

The Fusion logs should always report something because of optional Aero2 theme resource that I'm not using. Note that due to an issue with the wiki formatting an extra double quote was displayed at the end of the LogPath setting. So it should look like the following:

FusionLogOn.reg
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogFailures"=dword:00000001
"LogPath"="C:\\data\\fusion\\"
The path needs to exist and I'm assuming that you had the backslashes doubled up as per the example and that its just the forum markup that is displaying them as single backslashes.
Dec 13, 2014 at 9:01 PM
Edited Dec 13, 2014 at 9:02 PM
This DLL config you uploaded today, can we talk about this since you uploaded this morning? The date on the file says 10/17/2014 and it installs over the same file in the directory now but the app still doesn't work. Then, I tried to delete the old one and copy over the new one but it says to me, "You don't have permission." The one you uploaded for exe says Tuesday-12/9 when you uploaded it. Why is this dated October?

Finally, can you elaborate on the "path needs to exist statement" I know what that means but I have no "C:\data\fusion or C:\data\fusion and no search for "fusion" except for those two new registry files are showing.

Is this a hidden folder?
Coordinator
Dec 14, 2014 at 1:58 AM
Edited Dec 14, 2014 at 2:28 AM
Residentx10 wrote:
This DLL config you uploaded today, can we talk about this since you uploaded this morning? The date on the file says 10/17/2014 and it installs over the same file in the directory now but the app still doesn't work. Then, I tried to delete the old one and copy over the new one but it says to me, "You don't have permission." The one you uploaded for exe says Tuesday-12/9 when you uploaded it. Why is this dated October?
So I'm not sure where you are seeing these dates. On my machine I see the following:
daxstudio.exe.config - last modified 10 Dec 2014 - uploaded to the site on that date
daxstudio.dll.config - last modified 13 Dec 2014 0 uploaded to the site on that date

The permissions issue is because Dax Studio installs under "c:\program files" by default - you need to have administrator rights to change files in folders under that location. I think I have a working fix in the installer which I have not uploaded yet if you are interested in trying that.

To re-cap. The config files are only needed for people that only have the SQL 2014 client tools installed. If you don't have any of the libraries installed or if you have just SQL 2012 or both 2012 and 2014 installed then Dax Studio should work fine.

If you have just the SQL 2014 client without modified the daxstudio.exe.config file the User Interface will not load at all. Without the daxstudio.dll.config file the Excel add-in loads, but will report errors trying to connect to a PowerPivot model, but it works connecting to a server based model.

Residentx10 wrote:
Finally, can you elaborate on the "path needs to exist statement" I know what that means but I have no "C:\data\fusion or C:\data\fusion and no search for "fusion" except for those two new registry files are showing.

Is this a hidden folder?
There is nothing special about the path. It could be c:\blah or c:\windows\temp\foo - just create a folder somewhere on your system and put the path into the LogPath setting. I would suggest that it be an empty folder as fusion creates a couple of sub folders and it's easier to find them if they are not mixed in with other things.
Dec 14, 2014 at 2:13 AM
You caught me at a good time. Let me work on this right now. I have only SQL 2014 just FYI.
Dec 14, 2014 at 2:24 AM
Edited Dec 14, 2014 at 2:25 AM
Before I do this. Let me show you what I mean about the DLL.

Here is my dax studio folder now with the default files, http://1drv.ms/1wOjuuH

This is the new dll downloaded but I get those restrictions. You need to remove this. I don't have this authorization issue with other applications. I'm the admin on my machine I shouldn't be prompted, http://1drv.ms/1wtZIBp
Dec 14, 2014 at 2:29 AM
I'm making progress. I was able to install the file over. I couldn't do it directly. I had to download it locally and then move it over. Now the real test.
Dec 14, 2014 at 2:33 AM
Edited Dec 14, 2014 at 2:34 AM
No log dumps nor am I able to start this up standalone or through excel.
Dec 14, 2014 at 2:39 AM
When is your eta for the update. January?
Coordinator
Dec 14, 2014 at 4:36 AM
I've just uploaded a patched installer. I decided to simply replaced the installer in the existing 2.0.0.15 release as it's the same program files, the installer now just deploys the appropriate config file if it finds the SQL 2014 client libraries already installed. The best thing to do is to uninstall Dax Studio. Then download the new installer and re-install. I've tested this on a few different VMs with both the SQL 2012 and SQL 2014 client libraries installed and it seems to be working OK in those.
Dec 14, 2014 at 6:14 PM
Edited Dec 14, 2014 at 6:14 PM
Well Done, dgosbell, You had me worried there for a minute, https://www.youtube.com/watch?v=yPHVGjP74-w

Full speed ahead!