Interlink MSI Installer doesn't install Silverlight libraries

Jul 23, 2012 at 9:15 PM

After running both HSS Core and HSS Interlink MSI installers, at Visual Studio 2010, Add Reference dialog for a SILVERLIGHT project, I only see Hss.ServiceModel.Silverlight reference when I search for "Hss"

Do I need to copy the DLLs myself from the source and reference them from the project? I thought the MSI would add them to the GAC and that then I'd be able to add the reference and drop the upload control into my XAML or something

Jul 23, 2012 at 10:44 PM

Not sure, both the HSS Core and HSS Interlink libraries should both show up in the Add-Reference Dialog.

To clarify, the SDK libraries are not GAC'd but there are some non-sdk libraries (Common) installed with the HSS Core Framework (the ones NOT found in the HSS SDK folder, but the regular HSS Folder) they are GAC'd. Either way all of them should show up in the Add-Referance Dialog.

I just tested on a brand new machine and they both show up for me...

To confirm the installer was successful and made the proper Registry entries check the following registry key...

\local-machine\software\microsoft\.netframework\v4.0.30319\assemblyfolderex; in there should be the following:

1. HSS Core v4.0 Common Libraries
2. HSS Core v4.0 SDK Client Libraries
3. HSS Core v4.0 SDK Server Libraries
4. HSS Interlink v3.0 SDK Client Libraries
5. HSS Interlink v3.0 SDK Server Libraries

 

Jul 24, 2012 at 2:20 AM

I see HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx (with an "s"), but there are only some SSIS* subfolders in there

Jul 24, 2012 at 2:22 AM

I'm on Windows Server 2008 R2 and also it's a x64 machine, might those play a role? (e.g. maybe the installer can't place the files at the correct place and then doesn't update the registry?). I didn't see any installer error, does it keep logs somewhere or take some param to write a log?

Jul 24, 2012 at 2:30 AM

I just noticed the Silverlight project I was trying with was Silverlight 4 one, by changing it to Silverlight 5, now the Add Reference dialog shows the "HSS.Interlink" library

Jul 24, 2012 at 2:48 AM
Edited Jul 24, 2012 at 2:48 AM

Before being able to import the library, I had added UploadClient.cs to my project (need to call UploadStreamAsync to upload an in-memory stream as a file to the server), which eventually had me bring in also:

CustomEvents.cs
DelegateCommand.cs
FileQuery.cs
FileQueryCommand.cs
FileState.cs
IDelegateCommand.cs
IUploadClient.cs
Strings.resx
Strings.Designer.cs (this was autogenerated from Strings.resx after I set the custom tool to "ResXFileCodeGenerator" and the custom tool namespace to "HSS.Interlink")
UploadClient.cs
UploadFile.cs

Keep this as a mental note in case somebody doesn't want to pull-in the whole library for GUI-less uploads.

Speaking of this, maybe it would be best to partition the HSS.Interlink namespace into multiple assemblies, like HSS.Interlink.dll and HSS.Interlink.GUI.dll or something

Jul 24, 2012 at 2:52 AM

There are dependencies; why not just add a reference to the HSS Interlink Client dll versus mixing source code?

Jul 24, 2012 at 2:22 PM

I couldn't find the DLL initially (was a Silverlight 4 project as I found out later on, that's why it didn't show the HSS Interlink in add references - changing to SL5 it showed it fine). But the question is why would one not wanting to use GUI stuff, have to get the whole DLL pulled into their XAP and make their Silverlight deployment bigger (and thus taking more time) instead of splitting into two DLLs, one with the GUI-less stuff and another with the GUI that builds upon them.

Then people needing only GUI-less would reference just one of the assemblies, the others would reference both. Microsoft Silverlight and WPF toolkits, or SMF do similarly. One could also have a 3d assembly with all the parts together for convenience, but I don't see it as huge problem adding refs to two assemblies.

That is unless the GUI stuff aren't much in bytes (haven't checked out how much they take up extra)

Jul 24, 2012 at 2:25 PM

You're the second person to mention separating out the core from the UI stuff. Makes sense now that I hear it but at the time, most people want to leverage the UI components hence the combined dll. I will look into breaking them out into two separate components.

Thanks for the recommendation.

Jul 24, 2012 at 3:25 PM
Edited Jul 24, 2012 at 3:27 PM

I think there's some way for a HSS.Interlink.GUI assembly (dll) to reference HSS.Interlink assembly as required (a dependency) and have Silverlight pull that into the XAP even if you don't reference it directly (if you don't use some type that is defined in it and just talk to the GUI parts in a high-level way). Not sure how this is done though, maybe VS and Silverlight XAP packager do this automagically (see http://zoomicon.wordpress.com/2012/07/14/fix-the-tag-timeupdown-does-not-exist-in-xml-namespace-silverlight-toolkit/ for a case where it doesn't work correctly and MS are still looking into it...)

btw, it's fine when more than one assemblies define types in the same namespace, however sometimes its best to partition the namespaces too (e.g. move all GUI stuff to HSS.Interlink.GUI namespace or something to match the .dll name). I've seen SMF (from Microsoft) not follow this always and have .DLLs that just extend the same namespace with more types in many cases

Jul 24, 2012 at 3:31 PM

Not sure what you're asking...

I think you're just trying to give me a heads up, if I was to separate the GUI stuff from the Non-GUI stuff, correct?