I have several WF 4.0 workflows that I have created for an application my company is developing. Some of these workflows are simple, and some are very complex (i.e. many steps, several different types of activities, custom activities). For many of these workflows, I have created several custom code activities to support some internal process types.
The workflows work great and we have had very few problems when it comes to maintaining them within VS 2010. We now want to move that responsibility off to our business users, so I have created a WPF application to rehost the WF designer (according to the MS samples). My problem is that when I open one of the workflows that contains custom code activities, those activities are represented as red boxes with the error message of "Activity could not be loaded because of errors in XAML."
I have done research and have found several posts that mention that this is usually a problem with namespacing and referencing. The rehosted designer is in a namespace similar to this:
Company.Application.Workflow.Designer
And the custom code activities are contained within a separate custom workflow library, which I have included as a reference in the designer project. The library's namespace is similar to this:
Company.Application.Workflow.Data.Activities
As I have mentioned, the library is set as a reference in the designer's project, and I see it being copied to the output when I build the project. I have also included the reference in the XAML of the main designed application.
What am I missing?
There could be a lot of things wrong here. For one did you set the LocalAssembly when using the XamlXmlReader? See here for an example. Another problem could be your activities loading just fine but the related activity designers not being found. You can also use the AppDomain.CurrentDomain.AssemblyResolve event to see what assemblies are being loaded and failing. Or even better use Fuslogvw.exe for the same purpose.
Related
I have a solution with multiple Silverlight 4.0 applications, which all reference the same WCF service through a common Silverlight 4.0 assembly. That is each of the Silverlight UserControl applications reference a Silverlight assembly called "ServiceClient", also in the solution, to get their common OperationContract information. These UserControl apps reference that assembly.
When I change the WCF service I must update the "ServiceClient" assembly. This causes a large number of *.datasource files, and ServiceName.xsd, ServiceNameN.wsdl, ServiceNameN.disco (Where N is an arbritrary integer). All of these files are listed as pending changes in TFS. I must then carefully undo maybe hundreds of specific pending changes. Is there a way to limit file generation or at least supress their showing up as pending changes?
If you do not 'Undo" the pending changes and check-in, what happens?
If the files are checked-in then they were changed. Isn't that what you want?
I sometimes see VS/TFS set files to pending check-in, but when I perfrom the check-in the file list is cleard and the files are not checked-in (because there was really nothing changed in the files).
Maybe you are struggling with a non-issue.
It's not clear why you are undoing the automatically generated changes after a service reference update. When you buy into the VS Service Reference method that's part of the baggage.
If you want more control of the client generation process, you can use the SvcUtil command line utility. You will have to add build tasks to your projects to perform this if you want to mimic the Add Service Reference approach. I'd recommend going with a single project wired to use SvcUtil to produce a client assembly that all the other projects would reference. You still would need to add the WCF config file to each of the projects that reference your client assembly though.
Could you just reference the library in tfs which has you're service contracts, then use the contract to create a channel to your wcf service. Which would also mean you don't have to use a service reference anymore and also decouples your silverlight application from your service.
I seem having difficulty in understanding the reason behind the need of having many projects inside one solution (in my case visual studio 2010 with c#).
The only use that comes to mind is if I am creating a new classes I can test them in a console application first, then add another project to the solution to use these classes with the project that I want.
kindly guide me to the correct way, thanks.
A typical project might have a UI, a data layer, a services layer, and a domain layer, as well as some tests. A typical arrangement would be for each of these to exist as their own project file. The solution would contain all of these projects so that you can make modifications and debug different parts of the app at once.
If you're just starting out, you probably cram all of this stuff into one project. That's fine for learning, but is an absolute mess for maintainability and reusability.
There are 3 main reasons that immediately come to mind for splitting your solution into multiple projects: Reuse, Encapsulation, and Project-specific settings.
Reuse
You may have a Utilities project that is shared between more than one solution. You may also have data access and business rules that are defined in class libraries, but are shared between multiple UI projects, such as having a business application that has a web interface, a desktop interface, and web services. They all need to share the same logic and data model, so you wouldn't want to replicate it in each solution separately.
Encapsulation
Another reason is to achieve encapsulation, one of the main principles of OOP. Your classes may have internal methods and properties (or the classes themselves may even be defined as internal), which makes them only visible to other classes in the same project. If it's there to achieve a specific purpose but not something that should be accessible to all, by splitting your classes across separate projects you can make those properties, methods, and classes visible to your classes, but hidden outside the scope of your project.
Project-specific settings
There are certain project types that behave completely differently from one another. A Web Project is different from a Windows Forms app, which is completely different than a WPF app. This kind of goes along with #1 and trying to achieve code reuse; since you can't have a single project that is a website AND a Windows Forms app AND a WPF app, you create each UI as its own project and put as much logic as possible into a separate project that can be shared between all of the UI projects.
A couple possible reasons off the top of my head:
a project may be useful in more than one solution
simple organization utility - just like you might have classes in separate files even though a single source file can hold multiple classes just fine.
I have created a Silverlight class library which holds a lot of the common utility methods I use day to day in my Silverlight development.
I am starting to play around with Workflow and would like to reuse this common dll. After referencing this dll in my workflow project I see a yellow warning icon beside it.
I can use the functionality from this dll when creating ‘Code Activities’ without issue. After adding the using statement for it all works AOK.
using EquinoxeAISManagementSystem.Common.Helpers;
BUT when I try to import the dll from the activity designer, I do not see the dll in the import window.
If I edit the XAML and add it directly, I get a warning.
Is it possible to reuse Silverlight dlls?
I believe I can answer my own question.
The project EquinoxeAISMAnagementSsystem.Common is part of another solution. I had added this single project for the other solution into my new workflow solution (which I was having this issue in).
When I added the reference to the EquinoxeAISMAnagementSsystem.Common.dll initilly, it was by referencing the project in the workflow solution.
This seems to be the cause of the issue (for workflow anyway).
I was able to correct this issue by adding the EquinoxeAISMAnagementSsystem.Common.dll to a common folder where I keep all my external dlls (for ease of use).
..\Projects\EquinoxeAISManagementSystem.DLL\
I set up the output destination folder for this EquinoxeAISMAnagementSsystem.Common project to the folder above. I was then able to add the reference to Common.dll by browsing directly to the folder above.
Hay presto, all works.
I’m not sure id this is the ‘correct’ way to do things, but I needed to get over this hump.
I would be interested in anyone’s comments and if there is a correct(er), why to fix this issue.
Thanks ….
Currently I have 4 solutions that are independent projects, however there is quite a bit of duplicated code when it comes to a few areas of the applications.
At the moment it is simply a few forms and their associated code.
When I want to change or improve something, I have to copy and paste to all relevant projects.
I looked at creating a new project within one of the solutions for the .dll/class library, but I felt that this was incorrect. (Please say if I am wrong).
As it is a component for all the applications, I decided to create a new solution for the .dll/class library and am looking at moving the shared code over to that - but, having never gone down this route before, what are my options from here?
Am I able to then include this solution within the others if I need to make a simple change and have it updated in all the projects or instead, should I always be working on the shared component in a separate instance of Visual Studio, outside of the applications using it?
That's exactly the right way to handle this situation.
You can include projects in multiple solutions by right-clicking the solution and selecting Add Existing Project...
Any changes you then make will appear in all solutions. The only problem this leads to is that it's possible to break one solution from another. This is where automated builds on commit to source control come into their own.
Put shared codes in separate Solution/Project as Class Library,
In post build event of shared projects copy dll's to a specific directory,
Add shared dll's from this directory to other projects/solutions
By doing this each time you build your consumer projects, they will use latest dll's automatically.
Moving the common code into a separate shared assembly is an excellent option.
One thing to think about is to keep your common business logic or business object type code separate from UI related code like custom controls - if you need to then have two common assemblies. This is more work initially, but makes things way easier further down the track when you need to make UI changes or change the control suite you are using.
How do I create a Web Application Project in VS 2008? How is it different from a "WebSite" project?
File--New--Project
instead of File--New--Web Site
It acts as a different container all together and the compile model is different.
ScottGu provided some details when they were first launched: http://weblogs.asp.net/scottgu/archive/2006/05/08/445742.aspx
The main difference is that Web application uses .csproj file which holds the information about all the files in the project. What difference does it make? Using web site model you can add new files without visual studio, since adding new files doesn't require csproj file modifications, but using Web application model you can not.
I personally prefer Web application type.
People have adequately identified many differences, but let me add this broader stroke:
Web Application Projects are architecturally consistant with the other project types in .Net, whereas WebSites deviate and really seem like a throwback to the VS 2003 days.
For this reason, my opinion is that WAP's are more elegant (especially when you have more than one project in a solution).