I created a class library in C# for addinn and my Enterprise architect is loading it in Extensions but when I create a WPF application and change its output type to library but Enterprise architect is not able to load this library.
EA only reads ddl's as add-in that have an addin-class exposed to COM.
I'm guessing switching to WPF messed up the COM registration of your add-in class.
Some more info on writing add-ins for EA on my website
Related
We have two projects; one's a VSTO Add-in and the other is a TypeLibrary which exposes Outlook COM Interop calls by registering the assembly as a set of COM interfaces.
This setup has allowed us to communicate with Office products (Excel, word, and Outlook) from our old C++ executable. This has been working fine for nearly 10 years.
We've tried adding some Graph API calls and we're getting the following exception:
Exception thrown: 'System.InvalidOperationException' in Microsoft.Identity.Client.Extensions.Msal.dll
The graph api sdk calls I'm making work perfectly fine when in their own projects (e.g. .NET Core) as a class Library. However, when I add that working class library project to my legacy projects, I get the problems above.
Code Being Executed
await graphClient.Me.Request().GetAsync();
I am trying to access the My.Computer object in a class library project (Visual Studio CE). I know people say that I should find in Project Properties a "My Extensions" option - but it's just not there.
Microsoft site says the exact same thing but I just can't find that option.
To access the My Extensions page, double-click My Project for your project node in Solution Explorer. When the Project Designer appears, click the My Extensions tab.
https://learn.microsoft.com/en-us/visualstudio/ide/reference/my-extensions-page-project-designer-visual-basic?view=vs-2017
Besides that, Microsoft says the My.Computer should be available in Class Library project. Well, it's not. As a matter of fact My is totally empty.
https://learn.microsoft.com/en-us/dotnet/visual-basic/developing-apps/development-with-my/how-my-depends-on-project-type
LE:
Visual Studio Community 2017 15.8.1
.NET Framework 4.6.01055
Class Library type: .NET Standard
ANSWER: .NET Standard Class Library does not have My extensions. Use .NET Framework Class Library when creating the project to be able to access My objects.
u-blox's u-center is a desktop application for Windows OS that is light-weight and accommodates all the streamed data without problems.
What is the toolkit or framework (.Net "I doubt it", Win32 API, MFC) used to build such a desktop application like u-blox's u-center?
It is based on Win32 API and MFC. MFC is statically linked. See also the second page of the user manual.
https://www.u-blox.com/sites/default/files/u-Center_UserGuide_%28UBX-13005250%29.pdf
I have a C++ DLL project which is created in VS 2010. It is exposed as COM(ATL). I used this dll to another .NET Project as reference. C++ Project linker settings are set as follows:
"Register Output" = Yes
"Per-user Redirection = Yes
I created a build definition to build these two projects in tfs 2010. C++ Project builds fine, but .NET project fails because the output dll of C++ project is not registered. Setting to "Per-User redirection" = false does not work. I also tried using WF activity 'InvokeProecss' to register the c++ dll using Regsrv32/batch file/my own exe etc, but I get exit code of 5. My TFS 2010 is in Windows 2008 Server R2. And I think, it's not running the process as admin.
If I generate a interop dll using tlbimp, and then I refer that interop in my .NET proejct, it works fine(oviously in tfs build, I need to add InvokeProecss to call tlb). But this is not acceptable as our general practice is to refer a COM dll directly from .NET proejct.
Can anybody please help about this?
Is there a way to run the tfs automated build activity 'InvokeProcess' as Administrator without prompting for user name/password?
By default, the TFS Build Service runs as the "Network Service" account which is a relatively low-privilege account. Alternatively, you can configure it to run as any domain account you like. I wouldn't recommend that as a solution to the problem you described, however. I would agree with Hans that, in this case, it would be better to use the type library importer (TlbImp.exe) to "reference" your COM server from your managed assembly.
If the COM object isn't changing, you can just use the type library importer to generate an interop assembly, check that in and reference it from your .NET project. If it is changing, you can add a post-build step to generate the interop assembly rather than using the InvokeProcess activity. As Hans pointed out, you can't actually reference a COM object directly from a managed assembly. Your reference is actually causing an interop assembly to get generated at build time after resolving the reference to the registered COM server.
Our entire team installed VS 2010(It has both VSTO runtime 2010 and .net framework 4).After installing that some of our developers are getting the below error (but for majority its working fine) while opening the deployed VSTO application from server developed in framework 3.5 and VSRO runtime 3:
***** Exception Text *******
Microsoft.VisualStudio.Tools.Applications.Runtime.CannotCreateCustomizationDomainException: Customization does not have the permissions required to create an application domain. ---> System.Security.SecurityException: Customized functionality in this application will not work because the administrator has listed file://fmrdmwaprd2/CA-INSTALL/Demand/Templates/GeoDSS_Templates_UTT/APAC_RevOpt_OEM_Good_Bad_News/APAC_RevOpt_OEM_Good_Bad_News_UTT.vsto as untrusted. Contact your administrator for further assistance.
at Microsoft.VisualStudio.Tools.Office.Runtime.RuntimeUtilities.VerifySolutionUri(Uri uri)
at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.CreateCustomizationDomainInternal(String solutionLocation, String manifestName, String documentName, Boolean showUIDuringDeployment, IntPtr hostServiceProvider, IntPtr& executor)
The Zone of the assembly that failed was:
MyComputer
It sounds like your computers have "trust issues". Here is a link with more information about the trust levels for different locations / items and how you can change them:
http://msdn.microsoft.com/en-us/library/6exya3kf(v=vs.80).aspx
I also found this SO article that might be close enough to your issue to help you out:
Installing VSTO 4.0 Causes VSTO 3.0 Addin to quit working
I've run into this issue before and solved it. It's related to the fact that VSTO creates a custom AppDomain at load time for the VSTO AddIn. The action uses Shadow Copy to copy the VSTO .DLL into a temporary location and loads it from there.
Anti-Virus tools like McAfee actively kill this shadow copy operation, hence the AddIn will not load on protected computers, or any with tight security permissions.
To circumvent shadow copy, have your installer place your AddIn .DLL in the Global Assembly Cache. With it in the GAC, the Shadow Copy process is avoided, and the .DLL should load.
Keep in mind - this can cause issue with development, so do not deploy the .DLL into the GAC on your development machine. If you do, you'll not be able to run your changes in Visual Studio (the DLL in the GAC will run instead).