Latest Contributions by FreddieGibson

Yea...this workflow could work either way. The choice is just dependent on the environment you're most familiar with. Python would be a lot more flexible, but will require both knowledge of python syntax and programming logic. ModelBuilder won't require any knowledge of programming, but it will require that you understand its limitation when attempting to accomplish workflows that involve tasks that aren't run in a strictly linear manner. My only tip in exporting the models to scripts is to treat the scripts as skeletons that you need to clean up and not as ready-to-run scripts. If needed you can just make separate the models into their individual tasks and call the models directly from python to implement your logic. ... View more

I used to have an example that showed proof of this error a couple of years ago, but I haven't been to recreate it so far today. The answer to your question will probably be best described on the page mentioned by Domenico. You'll want to note that the page says "Sometimes when you use the new keyword to instantiate a COM object, you are getting a referent to an object that exists...If your code has encountered this error situation, you might receive an error, such as Unable to cast objecvt of type System.__ComObject to type <Typename>." The issue is more about a best practice. For a majority of people they'll continue to use the new keyword and they'll never run into this problem. The best practice to avoid this error if you were to ever run into it would be to use the Activator, but it's really up to the programmer to determine how they want to implement workflows related to this. For me, I ran into this issue when I started learning ArcObjects about six years ago, shortly after reading that page I just modified my workflows to use the Activator where needed and I haven't had to worry about this issue since then. Nowadays I use the Activator so much that I tend to forget that you can even use the new keyword. ... View more

I think that this is expected because both .NET 2.0 and .NET 3.5 use CLR 2 because Microsoft didn't release a CLR 3.0. A Microsoft Developer may be able to get you a more specific answer, but you can see in the image below that I get this same behavior in a pure C# application with No Esri Components. The application is compiled against .NET 3.5. ... View more

The upper limit for the buffer should be 2147483647 (i.e. Maximum value for a variable of type int).  The default value will be most likely be the 104857600 value you're seeing. HttpClient.MaxResponseContentBufferSize Property https://msdn.microsoft.com/en-us/library/hh193642 I ran into this error once before while downloading some rather large mobile geodatabases from a feature service. In my code I instantiate the client as follows: var client = new ArcGISHttpClient { MaxResponseContentBufferSize = 2147483647, Timeout = TimeSpan.FromMinutes(0.5) }; ... View more

I agree with Luke on this one. If you're trying to call the name of a tool on the fly you'll want to stitch together the call to the tool along with its variables so that you can execute an eval call. Otherwise you could use one script to literally write another script that calls the tool and execute the newly created script. This would equivalent to asking how to call a function in python on the fly without knowing the name of the function in advance. ... View more

Could you upload your map package so that I can take a quick look at it? Also, what version was your map package created against and did you use the user interface to create it or the Package Map geoprocessing tool? ... View more

You'll need to modify the schema for the dataset via IClassSchemaEdit to persist the change. This should be documented on the following page. Assigning domains to fields http://resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/#/Assigning_domains_to_fields/000100000121000000/ ... View more

For non-ArcObjects programmers or users that wants an out-of-the-box option you'll want to use Tim's solution. The attribute assistant provides a mechanism that does this. Otherwise you could implement a feature class extension in ArcObjects to handle this. ... View more

Hi William, Wanted to check in to determine if this is working for you? I would agree with a majority of the people on this thread that it sounds like the problem is with the targets path. ... View more

Sorry about that Dan. That was a typo on my part. It should say arcpy.management.MakeFeatureLayer ... View more

I think the expectation is that you should always use SpatialReference.Create. I used to always use the new approach until one of my colleagues made me aware of this a few months ago. This is documented on the following page: Guidelines and best practices https://developers.arcgis.com/net/desktop/guide/guidelines-and-best-practices.htm ... View more

Hi Tobias, The problem here is that sde connection information is stored within the map document. Even if you were to remove all of the layers the information is persisted so that data can be quickly added from that workspace in the future. I logged an enhancement for this issue in 2014. If you have a support account with Esri you can call technical support and we can get you attached to NIM092675 : Allow users to programmatically suppress or remove the sde login prompt from map documents that no longer reference data to a particular sde instance. If your original sde workspace still exists, do you still get the prompt after supplying the credentials on the original map, changing all of the datasources to your new workspace, and then saving the map? According to my notes, the MXD Doctor was able to remove the prompt for me when I leverage it to create a new map document. ... View more