Latest Contributions by GeraldMarbury

‎05-17-2017

Actually, this allows you to support both when it was collected and display it. Imagine a hypothetical hosted bill collection app that requires the power bill be paid to the remote technician by 5PM local time to keep from being disconnected. If you operate techs in Alabama and Georgia, that will be different time zones depending on where the technician was at the time. The mobile device will automatically change timezones when they cross the state line but the app can't store this information unless it uses two fields (Device Time and Time Zone) or a text field in ISO 8601 date. Both of these of course makes reporting, sorting and query more complicated. Storing the time as UTC is not enough either because depending on if the work was in Alabama or Georgia the due date may not have expired given the same UTC time. The three formats I listed above already handle this for the major RDMS. A related problem is that the ArcGIS REST endpoints use javascript numeric based dates to transport the data. This assumes all dates are UTC. See this issue for example. Problem: Date fields in a web map display incorrectly in the ArcGIS Online map viewer Dates should have the option to be transported as ISO 8601 strings instead of numeric so that time zone can be transported for each record.

‎05-17-2017

Actually, this allows you to support both when it was collected and display it. Imagine a hypothetical hosted bill collection app that requires the power bill be paid to the remote technician by 5PM local time to keep from being disconnected. If you operate techs in Alabama and Georgia, that will be different time zones depending on where the technician was at the time. The mobile device will automatically change timezones when they cross the state line but the app can't store this information unless it uses two fields (Device Time and Time Zone) or a text field in ISO 8601 date. Both of these of course makes reporting, sorting and query more complicated. Storing the time as UTC is not enough either because depending on if the work was in Alabama or Georgia the due date may not have expired given the same UTC time. The three formats I listed above already handle this for the major RDMS. A related problem is that the ArcGIS REST endpoints use javascript numeric based dates to transport the data. This assumes all dates are UTC. See this issue for example. Problem: Date fields in a web map display incorrectly in the ArcGIS Online map viewer Dates should have the option to be transported as ISO 8601 strings instead of numeric so that time zone can be transported for each record.

‎07-07-2016

Because mobile and browser users move between time zones as they create data, the nature of data in or age is that each row of a table can be collected in a different time zone. Because storing all dates as UTC is not always desirable, I suggest ESRI support the various date time data types that are time zone aware so that each date value in a row can know what time zone it was collected in. Time zone aware data types already exists in Oracle, SQL Server , PostgreSQL and I suspect other RDMS that the Geodatabase supports. Sql Server: datetimeoffset (Transact-SQL) Oracle: Datetime Datatypes and Time Zone Support ), PostgreSQL: PostgreSQL: Documentation: 8.2: Date/Time Types

‎07-07-2016

Because mobile and browser users move between time zones as they create data, the nature of data in or age is that each row of a table can be collected in a different time zone. Because storing all dates as UTC is not always desirable, I suggest ESRI support the various date time data types that are time zone aware so that each date value in a row can know what time zone it was collected in. Time zone aware data types already exists in Oracle, SQL Server , PostgreSQL and I suspect other RDMS that the Geodatabase supports. Sql Server: datetimeoffset (Transact-SQL) Oracle: Datetime Datatypes and Time Zone Support ), PostgreSQL: PostgreSQL: Documentation: 8.2: Date/Time Types

‎04-04-2011

:)I had no "Visible" dependencies on msvcm90. However, I was using Dotfuscator to link and obfuscate my assemblies. It appears the problem went away when a changed the setting "Emit Debugging Symbols" from "JIT Optimization; Sequence Points from MSIL". Theory: To emit debugging symbols, the assembly must be somehow tightly coupled with the 2.0 runtime, namely msvcm90.dll (although not visible via Reflector). When the 4.0 runtime was started via the "supportedRuntime version" tag in the ESRIRegAsm.config it had a reference to msvcm100 not msvcm90, thus causing the file not found error. This also explains why altering the config file of ESRIRegAsm got around the problem. I put all this is here so the next poor soul will not waste their time too. Happy hunting..

‎04-04-2011

When you have assemblies that will not load then: Use Reflector and walk the references. Using it sort of like the old Depends utility if you are old school. Unfortunately, RedGate charges for it now but it is worth it! Use the fuslogvw utility. Make sure to explicitly set a custom directory. How .NET finds and loads assemblies is complex. Oh how I miss the good-old-days of PATH:) tried fuslogvw *** Assembly Binder Log Entry (4/4/2011 @ 3:19:11 PM) *** The operation failed. Bind result: hr = 0x80070002. The system cannot find the file specified. Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under executable c:\Program files (x86)\Common Files\ArcGIS\bin\ESRIRegAsm.exe --- A detailed error log follows. === Pre-bind state information === LOG: User = Win7Test64\Tester LOG: DisplayName = msvcm90, Version=9.0.30729.4940, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (Fully-specified) LOG: Appbase = file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = ESRIRegAsm.exe Calling assembly : (Unknown). === LOG: This bind starts in default load context. LOG: Using application configuration file: C:\Program Files (x86)\Common Files\ArcGIS\bin\ESRIRegAsm.exe.Config LOG: Using host configuration file: LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. LOG: Post-policy reference: msvcm90, Version=9.0.30729.4940, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a LOG: GAC Lookup was unsuccessful. LOG: Attempting download of new URL file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/msvcm90.DLL. LOG: Attempting download of new URL file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/msvcm90/msvcm90.DLL. LOG: Attempting download of new URL file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/msvcm90.EXE. LOG: Attempting download of new URL file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/msvcm90/msvcm90.EXE. LOG: All probing URLs attempted and failed.

‎04-01-2011

1) "Any" minny miny moe: When creating ArcGIS desktop extensions it doesn't matter which platform you use because ArcMAP/ArcCatalog with be the process and it is x86. Eitherway I tried the x86 option too. 2) Why RegAsm: The only reason I used RegAsm was to try to debug what was going wrong with ESRIRegAsm. ESRIRegAsm registers the assembly and listens for COM writes to the registry. I figured if RegAsm was having problems too, the problem was not in ESRIRegAsm 3) Are you using .net 2010 professional or similar? VS2008 4) Which arc are you using? SP1 installed? ArcGIS 10 sp1 5) Have you tried contacting someone from ESRI? Not yet, I was hoping somebody was watching this blog. I'm currently working on a way to write the xml file myself and pass it to ESRIRegAsm. 6) Have you read http://help.arcgis.com/en/sdk/10.0/a...00002zp000000/ and http://help.arcgis.com/en/sdk/10.0/a...00004n6000000/ LOL--Of course many, many times. Even when back to 9.4 version to see what changed. . Thanks for your help Mike (Sorry O called you Robb)

‎04-01-2011

ESRI *.ecfg files only seem to contain a type to category mapping as indicated below. <?xml version="1.0"?> <Categories ver="1"> <Category CATID="{62C8FE65-4EBB-45E7-B440-6E39B2CDBF29}"> <Class CLSID="{1502B6C9-B57C-36E0-BCC7-C4CFDD058082}"/> </Category> </Categories> Since the path to the assembly is not stored in the ecfg file, how does ArcGIS know how to create the type? Does it use COM to CoCreate or CreateObject the type? Doesn't this require the types still be com visible and registerd in COM? If our types still have to be registered in COM, what's the benefit of not using component categories anymore? Please explain.

‎03-31-2011

When you compile, because objects are still 32 bit, you must choose x86 as a CPU, not using 'ANY', otherwise, it will as you stated, your program dll will look for 64 bit files that don't exist. Nice try Robb, I appeciate the quick response. I tried this and it still it didn't work. Like I said, what's weird is all my DLL's are "Any CPU" and some of them work, and some of them don't. The other interesting tidbit is since I made the change you suggested, although it does not create the ecfg files the error from RegAsm is not consistent with the error from EsriRegAsm. Now the 64bit RegAsm on the machine are raising "Failed to load XXXXXX because it is not a valid .NET assembly" where RegAsm used to say "Could not load file or assembly 'ESRI.ArcGIS.System, Ver sion=10.0.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86' or one of its dependencies. The system cannot find the file specified. C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe [DLL PATH HERE] and v/s C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe [DLL PATH HERE] but the EsriRegAsm doesn't mention "Fail to load", it's still says "cannot find the file" Excerpt of EsriRegAsm.exe output ********************************** ESRIRegAsm::Register Command line: "[DLL PATH HERE]" /p Desktop /e Registry Capture On. Registering managed library... Managed Exception: The system cannot find the file specified. (Exception from HRESULT: 0x80070002) Registry Capture Off. Operation Failed 04C10848 **********************************

‎03-31-2011

There appears to be a weird file not found error occuring on some custom DLL's when EsriRegAsm is being executed on Windows 7 x64. I believe ESRIRegAsm is loading Framework 4's 64bit RegAsm which in turn can't find the ESRI Framework 2.0 32bit dlls. I say this because, when I modified C:\Program Files (x86)\Common Files\ArcGIS\bin\ESRIRegAsm.exe.config from this <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0"/> <supportedRuntime version="v2.0.50727"/> </startup> to this <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v2.0.50727"/> </startup> ESRIRegAsm.exe worked... Also anybody thinking they can avoid using EsriRegAsm by using IComponentCategoryManager. Don't waste your time. IComponentCategoryManager does NOT register in the ecfg file. It puts it in COM! ESRI, it would be nice if there was a IComponentCategory2 that could read and write the ecfg's correctly.

‎01-08-2010

@domrorke thanks for starting this dialog.. I share all of your questions. Counterparts less powerfull? Another question I have is if there is a known ticking lifespan to COM customizations. I understand that there are limited customizations in the Addin framework. However, it also appears the the addins couterparts that ARE available are less powerful. For example, you can't change the bitmap, or tooltip or any other attribute persisted inthe XML, dynamically in an addin button like you can an ICommand. If COM is ticking like VBA and VB6 did. Then should the addin sustitutes be less powerfull than their counterparts? Ideal World The major benefits that COM provides are discovery (COM Categories) and interfaces. Interfaces are interfaces and all the supported langanges have them. Discovery is the essential part and addins solve the discovery problem beutifully, better than COM did. In an ideal world, I would like to see the ability to add the same interfaces (ICommand, IExtension, ITool, ILayer etc) to .NET classes that do not have to be comvisible or registered in a COMCatagory but are discovered using xml files like the addin framework. Is this where ESRI is moving with tools like ESRIRegAsm? The addin process depends on inheritance which is a great idea. Ideally I whish interfaces could still be used too, ESRI.ArcGIS.Desktop.Addin.IButton for example. Then I could have a button that works in both frameworks. A simular framework to this methodology is the ADO.NET framework. You have DBConnection to inherit from but it also implements IDBConnection.

‎11-23-2009

9.4 rocks I can't wait for it to get out. The following statement is made in the "Migrating ArcGIS 9.3 Desktop and Engine custom components to ArcGIS 9.4" document. "Additionally at ArcGIS 9.4, ESRI no longer provides policy files. Consequently, all ArcGIS 9.3 development projects ported to 9.4 must be recompiled." I have extensions that work on 9.2, 9.3, and 9.3.1. I believe requiring a compile is a grave mistake for at least 3 reasons. 1) Hinders incremental migrations A brave (or desperate) end user should be able to upgrade to 9.4 and at least try their third party tools. However, many organizations will not be able to take advantage of features because they depend on some third party partner who has not migrated thier code yet. So the entire organization has to wait to get the benefits of 9.4. This kind of defeats the purpose of great works like the "ArcGISÂ® 9.3.1 geodatabase direct connect for 9.2 clients." In fact, it's kind of fitting to quote from this tool because I believe the same reasoning should apply here also. "Various groups within an organization may have different requirements and timelines that necessitate their client applications remain at 9.2 Service Pack 5 while other groups want to upgrade to 9.3.1 clients [........] you can upgrade your geodatabase to an ArcSDEÂ® 9.3.1 release so your 9.2 clients can take advantage of functionality present in the software at 9.3.1, and leave other users on 9.2 Service Pack 5 or later service pack clientsâ??and they will still be able to make a direct connection to the geodatabase."--ESRI 2) Too hard for BP's to support Many end users are one or two versions behind the last stable release. Too often the partner needs to support both the new version and the previous versions with the same codebase and binary. Test me, put out a poll. 3) VB6 is dead, but COM is still alive--- isn't it? Because VB6 has been dead a while now, ESRI is doing the right thing to abandon it. However, even with the new addin model, COM is still supported. It seems like as long as COM is supported the policy files that allow for cross version deploments should be provided too. Also, it's not clear how to get the primary interop assemblies unlocked for deployment. Will the end user have to have the SDK? Keep up the good work

Online Status	Offline
Date Last Visited	‎11-11-2020 02:22 AM

My Ideas

Latest Contributions by GeraldMarbury

Re: Support the DateTimeOffset and TIMESTAMP WITH TIME ZONE column data types

Re: Support the DateTimeOffset and TIMESTAMP WITH TIME ZONE column data types

Support the DateTimeOffset and TIMESTAMP WITH TIME ZONE column data types

Support the DateTimeOffset and TIMESTAMP WITH TIME ZONE column data types

Re: EsriRegAsm.exe - creating *.ecfg files for Assemblies/Dlls on a build server

Re: EsriRegAsm.exe - creating *.ecfg files for Assemblies/Dlls on a build server

Re: EsriRegAsm.exe - creating *.ecfg files for Assemblies/Dlls on a build server

Doesn't the *.ecfg files STILL depend on COM for assembly location?

Re: EsriRegAsm.exe - creating *.ecfg files for Assemblies/Dlls on a build server

Re: EsriRegAsm.exe - creating *.ecfg files for Assemblies/Dlls on a build server

Difference in capabilities between Add-Ins and COM Extensions?

Recompile required at 9.4 / Policy Files

Re: Support the DateTimeOffset and TIMESTAMP WITH ...

Re: Support the DateTimeOffset and TIMESTAMP WITH ...

Support the DateTimeOffset and TIMESTAMP WITH TIME...

Support the DateTimeOffset and TIMESTAMP WITH TIME...