SHORT VERSION
We (my company; I'm not schizophrenic, so far as I know...) have a Sharepoint Online list that we would like to programmatically add an item to directly from Solidworks
MY QUESTION
Has anyone been able to come up with a Solidworks addin that can authenticate to Sharepoint Online using modern authentication?
I've been trying for a while now and am still coming up short. I don't want to say it's impossible, cause that seems silly. But I've pretty much exhausted every avenue that I have found while researching this issue. Any thoughts or comments would be appreciated.
SOME BACKGROUND
To save on typing, I use the following abbreviations:
Sharepoint Online SPO
Solidworks SW
Several years ago we were using Sharepoint on-premises and a very simple VBA macro directly in SW to accomplish this task. It worked perfectly then. A couple years ago we migrated to SPO. With that came the need to use modern authentication in order to access SPO. That pretty much meant the end of the VBA Macro - at least from SW.
For fun we directly ported the VBA to a Excel 365 - a Microsoft product 🙂. We hard coded some sample values that would have been read directly from SW and executed the macro. The code continued to work without issue and a new item was added to our SPO list. There is [apparently] an implicit permission process based on the user signed into to Excel which handles the authentication to SPO. That makes sense to me and is one of the few places where I'll give credit to Microsoft.
The next steps seemed obvious: figure out how to authenticate to SPO in code. So started the roller coaster ride...
It didn't appear that VBA could work with modern authentication. (If I am wrong, PLEASE educate me)
We have pretty good experience with PDM add-ins so this seemed like the time try getting into the SW add-in realm. That alone was a challenge. If you've never tried to write a SW add-in, give it a go, and maybe keep the Jack Daniels handy. We prefer C# for this code.
Everything after that is a bit of a blur. Apologies for my randomness. Here are the main concerns / issues / gripes
What is the right .NET to use?
I'm still not sure. SW, in my humble opinion, REALLY prefers .NET Framework. Sure, you can use .NET or even .NET CORE, but it feels really clunky and less polished. I've run into issues getting newer versions to work 100%. I'll blame Microsoft for a chunk of this issue, and SW for the rest. Again, PLEASE educate me if you disagree or know better than I do. I opted for .NET Framework 4.8
What is the best / easiest place in Solidworks for my Addin?
I don't know. I ended up using the Taskpane as a place to house our custom code. I mostly landed here because tutorials I found were for the Taskpane. But it also seemed like a nice place to put our code knowing that if I could make this work, we would likely add more functionality to this area. Keeping it all in the same Taskpane seemed ideal. That said, this does introduce some other calls to a UI which appears to be complicating my overall approach.
What authentication methods are available?
Initially the thought was to require no user interaction so we would be pretty much identical to the old VBA macro. Microsoft's App Authorization with a Client Secret seemed a perfect fit. While this is an enticing route, there are concerns. Client Secrets expire after 2 years at the most. Thus the code would periodically have to be recompiled and redistributed. More importantly, it is hard to lock down an Azure Application talking to SPO. There used to be a thing called Access Control Services, but it is now end of life: https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azuread Without that ability, anyone getting a hold of a client secret could gain access to the entire SPO site, which is unacceptable. Microsoft recommends a self signed certificate, which seems like more trouble to implement and swap out when needed. Not to mention it will have similar issues if it gets out in the wild.
All of that led me to going for an interactive sign in by the user. The end users won't like it, but it addresses all the security concerns, most importantly the peace of mind of our security team. Most of the examples I came across were for MSAL so that is the route I went.
What is the best way to interact with SPO?
Well, here's another place that Microsoft makes life difficult. The old SharePoint Client Side Object Model (CSOM) is the easiest, most complete method to access SPO data. However, Microsoft is pushing people towards their Graph methodology. It's not hard to find people that criticize the rollout of this method vs the old CSOM, and rightly so. Graph doesn't have all the functionality of the CSOM, and the interaction is completely different. So CSOM seemed like the winner. That was in my favor, I think, as it also goes back to the earlier days of .NET Framework. While I don't love being married to the older technology, it seems like .NET Framework was the front runner again.
Putting it all together
So, I landed at:
- .NET Framework 4.8 SolidWorks Addin, written in C#
- Interactive authentication via MSAL
- CSOM for interacting with SPO
But nothing has been smooth going. In my ideal world, I end up with a single dll with all the things needed to write to SPO from my Solidworks AddIn. In practice it's not ending up that way. I ended up creating a dll to handle the SPO operations that was separate from the SW Addin. A button in the Addin would call out to the SPO dll. I can successfully call the SPO dll from a basic Windows Form App, but I get errors when attempting to run it from the SW Addin. Also, all the other dlls required for the CSOM and the Microsoft Identity Client muddy up the project as well
Can you help??
I've spent more than a little time trying to make something work here. I still believe it's possible, but there is a lot involved getting it to gel, and I'm still not there. I am looking for any thoughts / advice / suggestions on how to make this work.
Thanks in advance!
Marc
