I have two client-side RIA services projects, each mapped to server-side RIA assembly for code-gen etc.. Let's call them domains A and B.
To make matters slightly more complicated, on the server side, domain project B references domain project A.
In project A on the server side, I create an Enum, and call the file MyEnum.shared.cs. I build it, and then build the client side (Silverlight) proxy projects. I then get a compile error: -
"The type MyEnum exists in both DomainProjectA.dll and DomainProjectB.dll."
The problem is that both my client-side proxy projects have copied this Enum file across, so the solution fails as its generated twice. I have proved this by looking at the hidden files in both proxy projects.
Why is this happening? How can I stop it from happening :)
Cheers
Isaac
I'm now fairly sure that this problem is caused because the type generation on the client-side proxy projects is sourced from all types exposed on the server assembly or any referenced assemblies; this also applies to .shared files.
Related
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.
I have a WPF application that accesses a number of WCF services. The WCF service addresses used in dev are different than those used in production (though their WSDL signatures are identical). What is the best way to setup the config files so that the proper service url is used for each type of build?
You can consider using a NANT process after build that change the config in a different way, here a discussion about that. An alternative is to create a MSbuild custom task, as discussed here.
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
I would like to know what are the industry standards or suggestion on how are you doing at your end for following situation.
I am creating multiple silverlight projects which get publised at different dates. All these projects uses varios shared code (common dlls). These shared code would be used in client side or server side. My question is, if the shared code changes would you recompile all the afftected project and release or recompile only when you are making change to the actual code which uses the shared component?
For now, client side, we create a assembly reference folder in each silverlight project and put the latest required dlls in it. By doing it, it has all required files in the XAP itself and it will not conflict with other projects and it works fine. With this approach I will not rebuild any other client side code just because common dll changed. If the common dll change is required for multiple projects then drop the latest copy in all affected projects and build them and distribute them.
On the other hand, the server side (Domain Services using EF), all the service code sit under bin folder of the web site. So if i would make a change to a common dll, then not only I need to publish the latest common dll for current project to work, but also recompile all the other services to use the new dll.
Would like to know your opinions and suggestions.
Thanks
There are two approaches possible:
Add Common Code to the solution and have a project reference
Get the build process to build to a folder and reference from there
I prefer first option. I always build and debug using the latest code and do not have to worry about stale references. I have used the second approach in the past and it is messy and can waste your team's time going after debugging bugs that do not exist (old version referenced). In fact I remember Visual Studio sometimes would not get a later version when it was available.
Another alternative for your Silverlight projects would be to use MEF to dynamically download a XAP file containing the common libraries. Then if the common libraries change, you could publish an updated "CommonLibraries.xap", and your Silverlight clients can pick up the refresh independently of the rest of the Silverlight application.
You could follow the same approach with other projects that use these common libraries. The applications could dynamically load the common libraries so that the common libraries can be refreshed independently.
If possible, consider consuming the "common library" code via WCF services.
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