We have a large Silverlight, WCF RIA based solution that builds just fine with VS2010 on my desktop. However, on the TFS server we are seeing the following:
ViewModels\MyVM.cs (47): The type 'TestService.Web.SystemAccount' exists in both
'd:\Builds\1\MyProduct\Binaries\Silverlight\TestService.dll' and 'd:\Builds\1\MyProduct
\Binaries\Silverlight\CommonService.dll'
.. and ...
Generated_Code\TestService.Web.g.cs (37476): The type 'TestService.Web.GroupToRule' in
'd:\Builds\1\MyProduct\Sources\Source\UI\TestService\Generated_Code\TestService.Web.g.cs'
conflicts with the imported type 'CommonService.GroupToRule' in 'd:\Builds\1\MyProduct
\Binaries\silverlight\CommonService.dll'. Using the type defined in 'd:\Builds\1\MyProduct
\Sources\Source\UI\CommonService\Generated_Code\CommonService.Web.g.cs'.
All was happy until a developer checked over the weekend (a very large check in unfortunately). We have looked at what changed in the changeset but haven't spotted anything.
We are using an approach similar to the one mentioned in this question and here, whereby we have a prebuild solution to avoid the circular references RIA code generation process can introduce.
Our suspicion is that the build order has been altered and are checking into this, but can anyone suggest some diagnostic steps or a solution for this?
It's hard to say anything reasonable based on the given info.
If you are sure that everything was built fine before some changeset, you could get logs of clean builds of that 'good' revision and of a later 'bad' revision and compare them. A good diff tool might help in this task. And some analysis tool, probably hand-written, might be necessary since MSBuild logs might be quite verbose.
Also, check out this answer in the topic you've referenced. That advice can be thought of as of an official one, since a guy from the MSBuild team suggested the same in one of their blogs.
We resolved what was the root cause (we think, at least it now compiles with MSBuild on TFS).
We have our own DomainServiceFactory to create WCF RIA domain service instances. Inside this factory we inject in the current authenticated user with a custom object (assuming the user has logged in and the domain service needs an authenticated user). Additionally, we have a common domain service that other services consume.
Ok that sets the scene.
The culprit in this mess looks to be the custom object we use to represent the authenticated user. Somehow we had arrived at the situation on compilation that this object was being seen from the common domain services and the other domain services that had a reference to the common one.
The solution was to separate the common domain away from the services that needed it by using the service locator.
Related
Let's say I have both the Production and Sandbox environments.
There are differences between the two - let's just say Sandbox has more modules installed, or the other way around.
I then generate a WSDL from Sandbox, add the Service Reference based on that WSDL and proceed to code up my application in .NET. The .NET application however uses only the methods which would be common to both Sandbox and Production environments, such as login(), query(), using the standard objects such as Lead etc.
Can I simply change the endpoint to point to Production and expect what I coded to work?
Yes. If the methods you are calling has same signature in both environment, nothing will cause the problem. If you alter the signature of the methods in service contract, that will cause runtime exception.
Also I would like to comment, if you change (ONLY addition of new members) the data contracts for these Service Methods, it will also work fine. For this to work, your service needs allow ExtensionDataObject. Any extra data from client will be stored in this object on the server.
Hope it answers your question.
As far as I'm aware, if you're only dealing with the standard API calls then yes, changing the end point should be enough. Of course you need to make sure you use the appropriate credentials and security token too!
When you create extra webservices via apex, they have their own WSDL to describe them — if you're using one of those then it should be the same for both environments if the methods are the same. As for custom objects etc., they're supported by the standard WSDLs.
For the sake of completeness, the Partner.wsdl is designed for connecting to different orgs rather than a specific one, so it is identical across environments and it's loosely typed, this may be the best one for your purposes.
A loosely typed WSDL for customers, partners, and ISVs who are building client applications for multiple organizations. It can be used to access data within any organization.
I am fairly new to Entity Framework and RIA Services, but I thought I had a reasonable grasp of it and was happily making changes to the entity model and adding subsequent changes to the Domain Service to provide availability to the client-side Silverlight application.
However, I made a change today to effectively introduce a many-to-many relationship on an entity, seemed reasonably straightforward. I then changed the Domain Service metadata to include the new EntityCollections that model the navigation properties etc.
This all seemed to go fine but when I tried to re-build the changes to the domain service they were not reflected in the client-side generated code.
I have tried absolutely everything, deleting the generated code, cleaning the whole solution and rebuilding, removing the RIA link and re-adding it, triple checking that the changes on the server side are correct (and they appear to be) and removing any code temporarily in the client that uses this entity so I can rebuild successfully.
I've pretty much run out of ideas as to why this code isn't being re-generated correctly. Any help would be greatly appreciated! Thanks.
This was due to RIA Services lack of support for Many-to-many relationships, just found this out.
So, i'm building my first SL application.
I tried to use the MVVM approach, and I think that's the way for me.
Basically, it's a simple application which shows data to the user, the data source is local (maybe in the future will be centric, but right now this is not the case), and the data should be retrieved by:
A. Calling file system's reading
and
B. Method calls from External DLLs
So, as I said, I started to work with MVVM (used this tutorial). I have 3 components: the service, the SL application and the project that host the SL app (excuse me if i'm not using the exact proffecional terms...).
My question is: Do you think that I've chose the right design? if so, is there any way not using IIS to host the service or is it a must? (I don't want to spend time on adminastrative tasks on clients' computers), because as I said, the data is local at the moment and IIS feels unnecessary.
I'll appriciate every comment on this. Thanks!
EDIT:
I'll try to simplify my question: I need my SL app to communicate with some kind of service - that will be able to take requests and reply back to the app.
This service suppose to be able to use .net dlls, and this service should be locally on each client run the app.
EDIT:
I noticed the Self host option.
Does anyone has any experience with it?
If your question is about: You having access to a database server somewhere, you should try WCF RIA Services. This will allow you to create service for each entity and the service will get included into your host project or you can even create a WCF RIA library.
As suppose to your MVVM pattern. I prefer splitting my Views from my ViewModels In different projects. I like to see them as a seperate layer.
Actually using ria services may mean that you have a number of services which apply to one user, but yes they are specific to the user. Which file system would you be attempting to access? The client or the server?
I finally decided to go with XBAP(WPF XAML Browser Application).
It suited perfectly to my requirements:
1. no deployment issues - just press a link, and .net enviroment will do the rest (downloading the needed assemblies, install them and finally run the app)
2. it's hosted on a browser
3. no IIS is needed!! it's a client-only application
Currently I have a working Silverlight application that uses .Net RIA Services.
It's structure:
Client-side
Application.Client.UI.dll (Xamls and
basic UI stuff)
Application.Client.BL.dll (Contains the Link to RIA and most of the business logic)
Server-side
Application.Server.Data.dll (Server-side dll that holds the Entity-model and it's generated domain service)
Application.Server.Web.dll (Only the ASP.net hosting container, which references the
Application.Server.Data.dll)
I placed most of the business logic on the client side (Application.Client.BL.dll) for better user-experience (fast reactions) and to free up server resources. My challenge is now to re-use this client-side dll including it's RIA data access capabilities, in a server-side windows service. I'm wondering, is that possible at all? Is the Application.Client.BL.dll still able to consume the existing RIA service, or does that dll require the Silverlight runtime to identify/locate it's service target, and therefore will not work anywhere else.
Curious for your answers
You really shouldn't put any business logic on the client, the guys in security and / or architecture will hate you for it ;-). Furthermore you can't use Silverlight assemblies in ASP.Net or Desktop projects and vice versa. If memory serves correctly, Silverlight uses an entirely different CLR altogether.
I encountered similar needs when working with compact framework assemblies I also wanted to compile for the full framework. I'll describe how I would work around this scenario.
If there exist any issues referencing the Silverlight assembly, consider building two projects as follows:
Project #1 would be your Silverlight library, and should contain all the source files you want to use on the client.
Project #2 would be your Windows Service. Instead of including source files directly, use the "Add Existing Item", find the original source file in project #1, then (and this is the magic), drop down the Add button to choose, instead, choose "Add as Link".
By including the source file as a link, you retain the ability to maintain your source code in one location, but add the ability to compile your code for multiple frameworks. As long as the code relies on assemblies available in both the Silverlight framework and the full .NET framework, then you're money.
Now, regardless of whether you choose a multi-project approach, know that domain context classes have additional constructors that allow you to specify contextual information, such as the URL, for the corresponding domain service. I use the following code in one application to construct a domain context for a domain service that provides personnel data:
var context = new PersonnelDomainContext(
new Uri(ConfigurationManager.AppSettings["PersonnelServiceUrl"]))
In this case, the URL looks something like:
http://website-url/Services/Hyphenated-Namespace-PersonnelDomainService.svc
Of course, when writing a Windows Service, nothing is stopping you from referencing the server-side domain service (not context) assembly directly. With the domain service in hand, you can instantiate a service instance without all the additional configuration and without the additional network XML payload. There are trade-offs to this approach, such as forfeiting centralized configuration management (such as connection strings), but depending on your circumstances, you may find the trade-offs to be worth it.
Happy coding!
Have you considered using fork-reuse? Take a look at:
http://sharednow.blogspot.com/2011/05/its-not-just-reuse.html
I am interesting in hearing if others have addressed release management for Silverlight applications.
I have a business application that is to be released shortly andam concerned about how to "release" updates to this application. Typically this application's users will leave the application open all day (and potentially all night) without reloading it.
What if there is is need to release an change that includes an web service interface change? How can this be deployed w/o causing errors on the client side?
We have grown so used to deploying ASP.Net apps by just dropping the latest code on the server. My only idea currently involves a client version number and a periodic timer on to check for updates.
I would love to know what others have done before implementing this.
Thanks,
Mike
I just answered a question on how to make sure that .xap files are not cached by the browser, which might be of some help:
Prevent Silverlight xap from being cached by proxy server
But that's no use if the users never reload your application. In my own application this is not a problem since users will be automatically thrown out whenever we deploy an update to the web service. But I like your idea with the timer, I would go with that.
Stating the obvious but don't do anything to annoy your users. E.g. could they spend twenty minutes entering data, nip off to the coffee machine and return to click Submit to find the timer has expired, noticed an update and their work is lost due to a forced restart?
If so, and I admit this hasn't had a lot of thought, if e.g. you have to make changes to the web service that break the current release, could you have the new web service version side-by-side such that users don't get thrown out until the timer has expired and the unit of work is complete? Or is this also stating the obvious?
For server code, i.e. endpoints just do as per normal. for the xap's I think you have a few options depending upon how you handle communications. You could have request contain a version number and if the server has been updated then force some code to reload the client, bit lame, messy but do-able. Perhaps a cleaner solution would be to control the clients session, which presumably is part and parcel with requests to the backedn. When you deploy a new version you could invalidate the client session, perhaps forcing a page refresh with custom logic. If your protocol is push base you could send a command to the client to do what ever you want, for many systems that are on all day its likely that this infrastructure would exist (if u've build it nicely :)). For instance our service layer is abstracted away from the repositories models and view models, in our case we'd could send a logout or perhaps a specific command to kick in some custom logic on the client informing the application is being updated and to refresh your browser when done. Our shell is light weight so our modules (basically other xap's) can be updated in time for the refresh.
I would recommend you to use a solution like mentioned in App Arch Guide:
The Guide Chapter I mean see Deployment considerations.
Divide the application into logical
modules that can be cached
separately, and that can be replaced
easily without requiring the user to
download the entire application
again.
Version your components.
Have you considered keeping a WCF polling duplex channel going that alerts the app when it needs to reload? In addition, you can have your WCF calls direct to a virtual directory that contains 'interfaced' calls. For example:
Silverlight app hosted at "x.x.x.x\Default.aspx"
Silverlight talks to WCF at "x.x.x.x\Version2\DataPortal.svc"
DataPortal.svc talks to a GAC (or otherwise base) assembly that can identify what version can handle what calls.
This way, if you upgrade to "x.x.x.x\Version3\DataPortal.svc", you can still make calls against Version2, assuming those calls have code to convert them to a Version3 concept.
This helps in cases where your line of business app has dynamic xap downloading ('main', 'customer', 'inventory', etc.) and you want to release them independently.