Trying to make an Wpf Application using ArcGIS for WPF running against Funbeat API to view tracks that I made. Building the application on Microsoft Prism, made a MapModule and a PersonModule and added to two regions in the app.
A Custom Graphics Layer was made that accesses the tracks through the Funbeat APIs. The project uses MVVM Views and ViewModels to separate the GUI from the model. The Xaml files are only using databinding to show the data.
Saturday, May 28, 2011
Saturday, May 14, 2011
Using NuGet to package ArcGIS WPF references.
Tested to use NuGet to create a package of the ArcGIS WPF APIs. Installed NuGet Package manager using extension manager in VS2010.
Installed the NuGet Package Explorer and created a package called ArcGIS.Client.WPF and added content, lib, framework and DLLs in the correct framework. Saved the package to a *.nupkg fil in a local folder C:\NUGet\Packages
To get make the package available to NuGet I added the folder in VS2010, Tools | Library Package Manager | Package Manager Settings
Now it's possible to use the package from a project, after starting a WpfProject in VS2010 I start up the consol by choosing, Tools | Library Package Manager | Library Package Console
when the console window opened up it's possible to choose the local folder that we added to the settings
Now it's time to install the package in the project, this is easy, only need to write install-package ArcGIS.Client.WPF and the package gets installed:
References to the package gets added to the project:
If we take look in explorer where the package ended up the filsystem looks like this:
So what's does all this mean, well you can create you own packages that can be easily be added in your projects. This makes it easier to handle dependencies and upgrades. There is a lot of packages on the NuGet Gallery but if you are missing a package or have internal DLL NuGet makes it easy to handle all external dependencies in your projects.
Installed the NuGet Package Explorer and created a package called ArcGIS.Client.WPF and added content, lib, framework and DLLs in the correct framework. Saved the package to a *.nupkg fil in a local folder C:\NUGet\Packages
To get make the package available to NuGet I added the folder in VS2010, Tools | Library Package Manager | Package Manager Settings
Now it's possible to use the package from a project, after starting a WpfProject in VS2010 I start up the consol by choosing, Tools | Library Package Manager | Library Package Console
when the console window opened up it's possible to choose the local folder that we added to the settings
Now it's time to install the package in the project, this is easy, only need to write install-package ArcGIS.Client.WPF and the package gets installed:
References to the package gets added to the project:
If we take look in explorer where the package ended up the filsystem looks like this:
So what's does all this mean, well you can create you own packages that can be easily be added in your projects. This makes it easier to handle dependencies and upgrades. There is a lot of packages on the NuGet Gallery but if you are missing a package or have internal DLL NuGet makes it easy to handle all external dependencies in your projects.
Friday, May 13, 2011
Ranting a bit on the changes in ArcGIS Server 10.1.
ESRI is changing the way the ArcGIS Server works in ArcGIS 10.1, See Considerations for ArcGIS Server developers: A look toward 10.1
We build a lot of SOA webservices leveraging the ArcGIS Server. These are mostly built using the pattern shown here: How to create a geocode and search Web service one of the reasons for building our web services using this pattern, was that the support for Server Object Extensions were poor and still is in ArcGIS 10. You needed to create COM enabled classes that has to be registered on the server etc, no tools, you need to write own tool (Or download SOExplorer) see: SOE Web services
To make the transition easier, I think that ESRI need to give us better tools to handle the SOE, SOAP and REST in ArcGIS Server and in ArcGIS Desktop/Engine. Also provide a solid pattern on how to build enterprise systems where the GIS systems can communicate with other business systems.
We build a lot of SOA webservices leveraging the ArcGIS Server. These are mostly built using the pattern shown here: How to create a geocode and search Web service one of the reasons for building our web services using this pattern, was that the support for Server Object Extensions were poor and still is in ArcGIS 10. You needed to create COM enabled classes that has to be registered on the server etc, no tools, you need to write own tool (Or download SOExplorer) see: SOE Web services
To make the transition easier, I think that ESRI need to give us better tools to handle the SOE, SOAP and REST in ArcGIS Server and in ArcGIS Desktop/Engine. Also provide a solid pattern on how to build enterprise systems where the GIS systems can communicate with other business systems.
Labels:
ArcGIS 10.1,
ArcGIS Server,
REST,
SOAP,
webservices
Monday, May 09, 2011
Subscribe to:
Posts (Atom)