I want to replace the Windows DLL that contains the label object. At first, I thought just each of the installs of the .NET Framework would contain it, but some applications don't utilize the .NET Framework and still have labels. I was wondering, what DLLs contain the label object? Is there only one (like, at the top that they all reference)? Do they all have it?
Related
I bought a new laptop and installed VS Community 2022 (used 2019 previously). I mostly create VB.Net console applications. I had to update a few of my utility apps and all worked fine. I then created a new app to automatically copy and rename photos from Google Drive to One Drive but I was surprised when standard libraries appear to be missing. For example:
Dim image As Bitmap = New Bitmap(Fpath)
shows a red underline below both Bitmaps and reports bitmap is not defined. Even if I change this to System.Drawing.Bitmap, it still says undefined. If I do type in System.Drawing, then intellisense shows only a few options Classes, Structures, etc. like Color, ColorConverter, etc. I had the same problem with System.IO.File.ReadAllBytes.
I uninstalled and reinstalled, selecting more options in case it needs other things. The System.IO.File.ReadAllBytes now works but System.Drawing.Bitmap is still undefined.
I can go to the menu item Project / Add Project Reference... and select COM, search for Drawing and 2 are shown (2.0 and 2.4). Checking either reports no errors however when I go back again, they remain unchecked.
Any suggestions?
In the .NET Framework, the Bitmap and Color types are both defined in the System.Drawing.dll assembly, so being able to access one would mean being able to access the other. In .NET Core, the Color structure is defined in the System.Drawing.Primitives.dll assembly, while the Bitmap class is defined in the System.Drawing.Common.dll. The former is a standard part of .NET Core and is cross-platform while the latter is part of the platform extensions that is specific to Windows.
As you have access to Color and not Bitmap, you have presumably created a project targeting .NET Core rather than .NET Framework. Note that .NET 5 and later are based on .NET Core. You need to either install the appropriate NuGet package to reference the appropriate assembly or else create a new project targeting .NET Framework. All the VS project templates that target .NET Framework say so in the name.
Since VSTO has yet not been ported to .NET Core, can I do it the old fashioned way and create a unmanaged shim to load the CLR and host the managed .Core 5 add-in?
My particular use case is an Outlook COM add-in that is currently built using VSTO against .NET framework 4.7 but I want to start leveraging .NET 5. In terms of interaction with Outlook, it just adds some buttons on the Ribbon and makes a few calls into the Outlook object model. I don't need to do anything like VSTO document based add-in in Excel for example.
I don't want to down the JS path as there is quite a bit of C# code that would need to be ported.
I found this https://github.com/jozefizso/COMShimWizard/releases which shows how to do it with the .NET framework, and am assuming its pretty close if not identical to what the shim wizard did back in VS 2010.
Since I need to load .NET 5 I believe to load the CLR I will need to do something along the lines of what is outlined here: https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting.
Before I dig further into it, is the approach likely to work? In particular, will in be possible to do necessary COM gymnastics to instantiate the managed components?
And assuming all this is feasible, will this be more or less equivalent to what VSTO does for .NET framework 4.x, i.e. is it less safe or performant in any way or will there be any functionality that won't be available compared with an add-in built with VSTO?
Update 1
I did some more research which raised some additional potential issues.
For the .NET framework case, once a class has been loaded into the CLR it is relatively easy to "unwrap" the returned reference to get a COM pointer which can be used to access COM interfaces that the type implements. It is not clear to me how this can be done when loading the .NET Core runtime using netfxr interface.
.NET Core does not have the concept of app domains, does that mean the multiple add-ins loaded into the Core runtime would not be isolated, or there a way to achieve some degree of isolation? From what I have read it seems that maybe their heaps would at least be isolated but I'm not sure.
Update 2
From reading this https://github.com/dotnet/runtime/blob/main/docs/design/features/COM-activation.md it seems that in Core, requests to types in assemblies as COM servers will result in auto loading the Core runtime (if it isn't already loaded) and create the object in a separate AssemblyLoadContext so maybe a shim is not needed at all? On the other hand it seems that if the Core runtime is already loaded and the version does match what is required by type you are trying to create, then the type will fail to load, so that seem to be a problem...
I'm working on a Solidworks Addin using VB.NET that utilizes the Solidworks API and CAMWorks API.
Basically, Solidworks has integrated a free version of CAMWorks dubbed "SolidworksCAM". The API dll reference for CAMWorks and SolidworksCAM are different, each with a unique GUID, but maintaining the same simple name of "Interop.CAMWorksLib.dll". The API functions are 100% the same, just each software ships with a different GUID for their API. This GUID ties back to the COM assembly loaded in Solidworks, so if Solidworks has SolidworksCAM loaded and my addin is complied with the CAMWorks API reference it will fail to retrieve the COM object.
How can I achieve compatibility between these two APIs without having two projects? Is it even possible? Thanks!
Whenever I post a question to a board it seems like I always solve it soon after.
For future reference, I used Reflection to dynamically load the Dlls. Below is some more detailed information.
I put the Dlls in two different folders in my project and set them to Copy. I then used Assembly.LoadFile to load the dll and get its assembly. I used this assembly to get the constructor class "CWAppClass" and fed its type into Activator.CreateInstance to get an instance of the main CWApp class. This way you can use whichever one doesn't error. Thanks for the help!
After taking advice to not use LoadFile(), i have found that there is a method in the Solidworks API that allows you to do this. By using Sldworks::GetAddInObject you can get the addin object for whichever addin you choose. Then you can use the CAMWORKSADDINLib to interact with this. Thanks for the suggestion, this it the perfect solution for my problem.
I have a working Windows Forms app (split into an EXE and a few DLLs). Now I've been asked to look at creating another app (MyAppLite) that has only a very small subset of the functionality. Think of it as similar to MS Word Viewer vs. MS Word.
Everything that I need to build MyAppLite is contained in the main solution - essentially I need to use a couple of the WinForms and whatever bits in the DLLs they call into.
What would be the best way to do this?
I was thinking of creating another Project in my solution for MyAppLite, then adding the necessary source files as links (using Add Existing Item > Add As Link in Solution Explorer).
I definitely wouldn't want to maintain 2 copies of the source code.
FYI it's a .NET 2.0 VB app, using VS2008.
You can create a new class library to contain your forms that are common to both projects. Create the new project and copy the forms from the original project into the new class library. Then you can import the class library into both the original project (after removing the original versions of the forms) and the MyAppLite version. If you need to change the forms, change it in the class library and then recompile your applications
You could refactor your project so that it would keep the common functionality in a MyAppCore project, and reference that from both MyApp and MyAppLite. The core dll would contain all the common functionality and take parameters as to what to allow and what to restrict, so the set of features in your lite version is customizable(say you have a customer that reaaaallly wants a preview of a certain feature).
I have an application that uses many different .NET managed DLL's as objects (each DLL implements a common interface). Each DLL also has a version number in the file name.
Suppose I create the object "Shape~01.dll." The application will use that DLL but it can't be replaced while the application is running. So, if I want to "upgrade" the shape dll I have to create "Shape~02.dll" and the application has to dynamically search for and load the newest dll everytime a shape is created and/or the user has to restart the application. It get's worse, each dll depends on the main .exe thus has to be rebuilt with the main .exe.
Is there an easier method to have dynamically "replaceable" objects?
Well, this isn't the best solution (still thinking about it), but you can unload dll files which will allow them to be replaced. That might be a quick stopgap solution until you come up with a better idea.
You don't mention which language/platform you are trying to accomplish this in, so I will answer for the .NET Framework.
If you want to do it the hard way look at Shadow Assemblies, this is the method that ASP.NET uses to keep the site updateable though it is using the files.
For a much easier method look at the new System.Addin namespace, this uses Shadow Assemblies under the hood and should do what you want.
Instead of polling when creating an object, why not just request notification from the system when the file system changes?
The class is System.IO.FileSystemWatcher in.NET.
For native code there are a few ways to watch a folder, but IANAND (I am not a native developer ;).
Although having said those things, you probably want to rethink the reason you need to change your objects so frequently, because it will probably take a lot of work to make it work.
You used the dynamic tag, so maybe you should try a dynamic language? :)