Latest Contributions by mfcallahan

This issue is occurring in ArcGIS Pro 3.0.3, 3.0.4, and 3.1.0; ArcGIS Server version is 10.8.1. Esri has confirmed this is a bug (BUG-000156390). Pretty frustrating as it is claimed here that Microsoft Azure Database for PostgreSQL (Single Server option) is supported by Esri, but it doesn't appear to be fully so. https://desktop.arcgis.com/en/system-requirements/latest/databases-in-the-cloud.htm   ... View more

I am using the Single Server Azure Database for PostgreSQL deployment. I am also using the "username@hostname" credential - omitting the @hostname will not allow login on any client, Pro included. The issue here is that the connection string generated by ArcGIS Pro appears to be truncating the "@username" ... View more

Upvoted - an officially supported "ArcGIS Pro debugger" VS Code extension would make all my GIS dreams come true 😃 I would love to see a workflow that allowed me to attach VS Code to a the Python environment of the running ArcGIS Pro instance, execute a script tool, and be able to hit breakpoints, step thru the code, etc. from within VS Code. Just like PyCharm and Visual Studio. Dear Esri: VS Code is used by 75% of the respondents to the 2022 StackOverflow survey! This would not necessarily be a niche tool, it could have a wide-reaching impact on developers. It's very likely that there a lot fewer GIS devs are using Visual Studio and PyCharm than there are using VS Code as their daily driver development environment. There is certainly precedent for something like this - are many such "Debugger" extensions available in the VS Code marketplace for a wide variety of languages/frameworks/platforms. C'mon Esri...you're good at this type of stuff - the Adobe Suite plugins, ArcGIS for Teams, Office, etc. Y'all got tons of cool integrations with lots of things, especially from Microsoft. I know the community could develop this (and I'd love to participate in such a project) but I like staying in the Esri ecosystem if possible. And officially-supported VS Code extensions are always much higher quality. Thanks, A GIS dev ... View more

If PyCharm can do this, there's got to be a way for VS Code to do this as well 🤔 I would definitely love to see an official Esri "VS Code ArcGIS Pro Debugger extension" ... View more

Yes, that would be amazing, but everything I've read while investigating the same thing seems to indicate that it is not possible.. If I could have a workflow similar to Visual Studio ArcGIS Pro Add-in development with VS Code & Python by attaching the debugger to the running arcgispro.exe instance I would be so happy 😀 ... View more

Ha! Well, I'll give some credit where credit is due..not a lot of software companies have made a game that still works flawlessly 32 years later (on an operating system that didn't even exist in 1990!)  MS Solitatire (1990) running on Pop!_OS 22.04 (2022) ... View more

You da man, @Brian_Wilson - thanks for replying, this worked for me! I had a very frustrating call with an Esri tech support representative for an hour trying to work thru this, but it ultimately ended it with a "we don't support this" answer and the ticket being closed 😑 I probably wasn't communicating things effectively to support, but Pro/ArcPy/Conda and actually using them is something that is so under-documented that even Esri's staff can't answer questions about how this type of stuff is configured.. ... View more

Wow, thank you for the reply 4 years later! Since then I've had a few different jobs, but I'm actually back at the same company, and have been tasked to again investigate this same thing! My manager inquired about how it would work with Active Directory, and I remembered that I had asked this question once upon a time.  Low and behold, there was an answer! I'm going to give this a try and will report back with my experience! Thanks again! ... View more

For what it's worth I came up with a strategy, using the Dependency Inversion Principle and the Facade Pattern, to be able to mock ArcGIS JS API modules and eliminate the HTTP requests being made from loadModules(). I posted in greater detail on my blog here: https://seesharpdotnet.wordpress.com/2020/12/03/angular-and-arcgis-api-for-javascript-a-unit-testing-strategy-using-dependency-injection-and-the-facade-pattern/ A working sample application applying this approach and test coverage is available in this repository: https://github.com/mfcallahan/angular-cli-esri-map-unit-testing Here is the summary from the repo's README file: The problem The esri-loader allows an application to load Dojo AMD Modules outside of the Dojo Toolkit. A module can be lazy loaded, improving the initial load performance of the application by waiting to fetch API resources until they are actually needed:     // MapService class to encapsulate ArcGIS API @Injectable({ providedIn: 'root' }) export class MapService { mapView?: esri.MapView; async initDefaultMap(): Promise<void> { // loadModules() will make HTTP requests to arcgis.com to fetch specified modules const [Map, MapView] = await loadModules(['esri/Map', 'esri/views/MapView']); this.mapView = new MapView({ map: new Map({ basemap: 'streets' }), center: [-112.077, 39.83], zoom: 5, }); } }     However, this can make unit testing difficult, as the system under test does not have any reference to the objects in an ArcGIS API module until an HTTP request is made to fetch it. A test for the initDefaultMap() method will call loadModules() and make HTTP requests to arcgis.com to fetch the resources needed. This may not be desirable for a few reasons: The test becomes more like an integration test; we want to assert the component.mapView was correctly set inside loadModules(), not test that the application could connect to the internet and fetch dependencies. Tests may be executed in an environment which may not have access to the ArcGIS CDN, such as an automated build pipeline or server. Tests to ensure error responses from the request to load an ArcGIS API module (the unhappy path) are handled properly may be necessary.     // initDefaultMap() unit test it('should initialize a default map', async () => { await service.initDefaultMap(); // test will make actual HTTP requests! expect(service.mapView).not.toBeUndefined(); });     My solution Difficult to mock code is difficult to test! By refactoring the application code to follow the Dependency Inversion Principle and leverage Dependency Injection, the tight coupling between the above initDefaultMap() method and the esri-loader can be eliminated. The Facade Pattern can be used, creating a wrapper class for loadModules() and others methods exported by esri-loader which can then be injected into the class that has a dependencies on ArcGIS API modules. The wrapper class exposes its own loadModules() method which can be easily mocked, eliminating HTTP requests to the ArcGIS CDN in a test suite. A library such as TypeMoq can be used to create mock instances of the various ArcGIS API modules.     // Singleton service wrapper class for esri-loader @Injectable({ providedIn: 'root' }) export class EsriLoaderWrapperService { constructor() {} public async loadModules(modules: string[]): Promise<any[]> { return await loadModules(modules); } public getInstance<T>(type: new (paramObj: any) => T, paramObj?: any): T { return new type(paramObj); } } // Updated MapService class @Injectable({ providedIn: 'root' }) export class MapService { mapView?: esri.MapView; constructor(readonly esriLoaderWrapperService: EsriLoaderWrapperService) {} async initDefaultMap(): Promise<void> { const [Map, MapView] = await this.esriLoaderWrapperService.loadModules(['esri/Map', 'esri/views/MapView']); const map = this.esriLoaderWrapperService.getInstance<esri.Map>(Map, { 'streets' }); this.mapView = this.esriLoaderWrapperService.getInstance<esri.MapView>(MapView, { map, center: [-112.077, 39.83], zoom: 5, }); } } // Updated initDefaultMap() unit test it('should initialize a default map', async () => { // Arrange const mockMap = TypeMoq.Mock.ofType<esri.Map>(); const mockMapView = TypeMoq.Mock.ofType<esri.MapView>(); const esriMockTypes = [mockMap, mockMapView]; const loadModulesSpy = spyOn(service.esriLoaderWrapperService, 'loadModules').and.returnValue( Promise.resolve(esriMockTypes) ); const getInstanceSpy = spyOn(service.esriLoaderWrapperService, 'getInstance').and.returnValues( ...esriMockTypes.map((mock) => mock.object) ); // Act await service.initDefaultMap(basemap, centerLon, centerLat, zoom, elementRef); // Assert expect(loadModulesSpy).toHaveBeenCalledTimes(1); expect(getInstanceSpy).toHaveBeenCalledTimes(esriMockTypes.length); expect(service.mapView).not.toBeUndefined(); expect(service.mapView).toBe(mockMapView.object); });       ... View more

Thanks, adding a similar configuration to my project looks like it would resolve the path issue I was seeing.  I ultimately abandoned moving my the project to the arcgis-webpack-plugin, but I will likely refer back to your answer in the near future with other projects.  Thanks for taking the time to help! ... View more