Its a long shot, has anyone used Esri ArcObjects recently?
According to the docs:
A new requirement is runtime binding. Runtime binding refers to locating the appropriate ArcGIS product installation of a stand-alone ArcGIS Desktop or Engine application before any ArcObjects code (including license initialization) is called. The application programming interfaces (APIs) to establish runtime binding are in the ESRI.ArcGIS.RuntimeManager class in the ESRI.ArcGIS.Version assembly
But I cannot find ESRI.ArcGIS.Version.dll anywhere. I have the trial version of ArcMap 10.1. Does anyone know how I can get hold of this DLL?
ArcObjects is the ArcGIS API, not part of ArcMap. You use it to build GIS applications using ArcMap's engine, but you need more than just ArcMap to do it. Unfortunately it costs money to get hold of ArcObjects - the bit you're looking for is ArcGIS Engine:
http://www.esri.com/software/arcgis/edn/what-you-get
Of course, it depends what you're trying to do - if you want to do some custom coding inside ArcMap, you may be able to do it with ArcPy:
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//000v00000001000000
Are you using Visual Studio? If so you need to add a reference to ESRI.ArcGIS.Version in the project references window. It will be under the ".Net" tab when you click "Add Reference.".
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.
I'm writing a Windows Phone framework with Windows 8 in mind. That means I'm creating a Portable Class Library (PCL) to be used in both platforms.
Right now my PCL is targeting .NET 4.5, Windows Phone 8 and Windows Store apps, as you can see in the project properties.
In that project I need to use Path.DirectorySeparatorChar but I get the following error from the compiler:
System.IO.Path' does not contain a definition for 'DirectorySeparatorChar'
I understand that that particular char might be different in the different targeted OS (I really don't know if they are) but why is the compiler complaining about it? I mean, the property help doc says it is supported by .net framework 4.5, am I targeting the right framework? Is the PCL really targeting the full .net framework 4.5?
With respect to Path.DirectorySeparatorChar:
As far as I remember we've removed it from Windows Store in order to discourage manual parsing of paths. In general you should use Path.Combine() for assembling paths and Path.GetDirectoryName() for splitting them up. In order to check for invalid chars, there is another method that allows retrieving those.
So practically speaking, what do you need the property for?
Update: To answer your original question around understanding profiles: The profiles represent API intersections between the platforms you've selected in the PCL dialog. Generally speaking, the fewer platforms you target and the more recent the versions, the more APIs you get. Checking all platforms in the oldest version basically gives you the lowest common denominator.
Since you've targeted .NET 4.5 and .NET Windows Store, you can't access Path.DirectorySeparatorChar because that property isn't included in Windows Store.
So, here's the actual answer to this question taken from the MSDN forum.
When you are creating a PCL, you can only have a subset of API-s that are defined in that particular profile. A profile is a list of API-s visible in all platforms.
Now, even if some API exists in both individiual platforms, this doesn't mean that it will automatically be in the PCL profile. Why is it missing is anyone's guess, but you cannot infer those reasons yourself.
If you take a look at the official documentation on MSDN (Cross-Platform Development with the .NET Framework), you'll notice that there are several constraints on what can be shared. I guess that that particular property doesn't satisfy those constraints.
And a good way of knowing is a particular method is supported relies on the icons of the documentation
Your PCL can use .NET methods which are available to all of its targets. Since PathDirectorySeparator isn't available to Windows Store apps it isn't available in PCLs targeting Windows Store apps. You can see that it doesn't have the green shopping bag marker for store support at http://msdn.microsoft.com/en-us/library/system.io.path.aspx
I can't seem to figure out how to get F# TypeProviders to work in a Windows Store (C#) app.
As far as I can tell, TypeProviders can only be used in an assembly targeting the full .NET Framework, whereas Windows Store apps must target .NET Portable.
I have created an F# assembly and referenced the F# TypeProviders library, however when attempting to reference this assembly from my Windows Store app, I receive an error stating that the library could not be referenced.
Is there any way around this? I want to use F# TypeProviders to reference various data sources and then use the generated code/types in my Windows Store app. Anyone have experience with this?
UPDATE:
Just to be clear, I am asking if there is a way to use the standard F# TypeProviders (such as WsdlService) in a Windows Store App?
Looking at the other assemblies FSharp.Data.TypeProviders.dll is referencing, I don't think there is a way around this. Since most type providers are used for accessing a database in one way or another (ADO.NET, LINQ to SQL, EF), it references System.Data.dll which is not available in WinRT.
The only data sources supported by built-in type providers that can be used in WinRT are web services and OData services. Their type providers maybe could be supported in a WinRT project if they were implemented in a separate library, but not in their current implementation.
Type providers are design/compile time facility. It should work in Portable library profile. It is maybe dependent on how is type provider library implemented, but in general, it should work.
For more info see F# type providers with Portable Library
Are there any libraries available that can help to change the look-and-feel of Desktop Applications made using VB.net 2008? Here is a snapshot of an application that runs on Windows 7:
I think its made using the .net framework, but how can it be styled like this?
PS - Even if its not built using .net framework, then please let me know which language supports the UI customization on windows platform.
NOTE - As everyone is suggesting me to go with WPF or SWING using JAVA, I still want to know if its possible in VB.net WinForms or not.
Theme handlers (Use standard controls and the handler takes care of the visual UI):
Open source
http://www.codeproject.com/KB/miscctrl/FancyNetForms.aspx
Closed source
http://www.appface.com/ ($ 149 USD) (Skin your app with 2 lines of code)
Special controls that has built in theaming:
ComponentOne:
http://www.componentone.com/SuperProducts/StudioWinForms/
Infragistics:
http://www.infragistics.com/
I don't know how this specific window was styled, but there are many posibilities:
Maybe was made in WPF. Microsoft WPF are available since VS2008 and Framework 3.0 and it allow to make a complete look and feel customization for every control that you use.
Maybe It was made in winforms using a custom control set. For example, DevExpress has a set of 60 free controls that comes with some predefined look and allow creating your own skin. (60 Free Controls)
Maybe It just was made in Java with Swing (look this Question)
I have an ASP.NET VB.NET web project that references a VB.NET class library.
I add a new property to a class in the class library, then, from the web app, I expect to be able to use it immediately w/o errors and with full intellisense.
It used to work in 2008.
When I compile the class library, it becomes available but not until.
Was this nice feature taken away, perhaps in the interest of speed?
What's likely happening here is that the Class Library and ASP.Net applications are targeting different versions of the framework. If they are using incompatible versions of the framework then VB.Net will treat it as a file reference instead of a project reference and would give you the behavior you're seeing.
Right click on the project, select the Appilication Tab and make sure that both have the same value selected for Target Framework. That should fix the problem.
Visual Studio 2010 will officially launch on April 12, 2010. I'd say there's a good chance that problem will be fixed in it. Go see.
EDIT: corrected the date.