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.
Related
I called IVsBuildableProjectCfg.StartBuild in a Visual Studio extension to build a project.
var ret= cfg.StartBuild(pane, VSConstants.VS_BUILDABLEPROJECTCFGOPTS_REBUILD);
But it doesn't start building. Instead it just produced exceptions.
System.InvalidOperationException: 'The operation cannot be completed because BeginBuild has not yet been called.'
How can it be called correctly?
background
Originally I called IVsSolutionBuildManager2.StartUpdateProjectConfigurations, but when projects are configured not to be built in Configuration Manager in a solution, StartUpdateProjectConfigurations doesn't build them.
Of course this is ideal behavior because IVsSolutionBuildManager is based on solution configurations including Configuration Manager.
But even in such a case, I want to build specific projects. Actually some of the extension users wanted that and I also think it's useful.
https://github.com/Wakusei/BuildStartProject/issues/2
I'm maintaining a VB6 application with many COM components (DLLs and OCXs). In order to streamline development and deployment I'd like to use reg-free com. The problem with development is that the application runs within the VB6.EXE instance. How can I trick VB6 to use my (unregistered) components? It is very important for me to not have to go through registering/unregistering components when switching between branches. Generating a .manifest file for VB6 is not out of the question but is there some other, more optimal way, to specify a .manifest file when launching VB6.EXE?
Note: The Activation Context API doesn't seem to help, even if used from within the development environment.
Solutions I've thought:
A utility application that activates a context from a manifest and launches VB6 as a child process (doesn't work; processes don't inherit activation context)
Injecting context activation into the VB6 process at startup (too complicated; must hack the executable to do this)
Hosting VB6 in my own process after activating the right context (can't even find out if this is possible)
Using a VB6 Add-In or other utility that runs within VB6 to activate a context (tried that but it doesn't seem to work)
Update Jan. 16
As suggested by wqw, I did some testing with a VB.exe.manifest. The VB6.exe.manifest worked, with some caveats:
The SxS dll specified in the manifest would not appear in the references window on projects that didn't actually reference the component
On projects that did reference the component it would be shown to reside in the directory according to the following order:
The pathname recorded in the project file (if the file was still present)
A pathname as if it resided in the same folder as the project (vbp)
If the file was not in any of these folders, the project would not compile (just running the code causes an internal compile in VB6) with the message "Can't find project or library".
Obviously, VB6 actualy scans the registry to find COM components and verifies, during compilation, that they exist where they say they exist. I'm not sure what that might mean if I actually want to use VB6.exe.manifest to redirect COM component instantiation. Perhaps having dummy component files at some predefined location might trick VB6 into believing that everything is as it should be, although an entirely different set of components got loaded for use.
Further update:
I did a test on that last assumption and it proved to be false. The component has to actually be there in order for the project to compile. It must even properly load (no dummy, zero-length files accepted!). Now I'm not even sure if the manifest works. That's a more time-consuming test (requires a component with two versions that produce different results, one with the project, and one for the manifest).
Our approach to this problem was to write a build assist program that registered and unregistered components, run the VB6 compiler, and would even rewrite project files with updated GUIDs when interfaces changed. You would hand it a VBG project group and it would do the rest.
I suppose we could also have added a mode that unregistered components when you switched branches.
Are you following the practice of using "compatibility" binaries? You shouldn't use the binary at your build location for compatibility references - you should commit a separate copy to version control and configure your project to consider that the "compatible" version - only change this file when you break interfaces.
So it seems like I have a couple of major options when getting WCF service proxy code into a project in Visual Studio:
Use Visual Studio's built-in tooling for Service References
Use a simple svcutil command, something like svcutil http://[my
endpoint] /namespace:[my namespace] /noconfig (since I use some
fairly standard bindings across projects), and drag the resulting
file into my project (or upgrade in place).
To be clear, option 2 feels like the best one, albiet with no built-in tooling for updating. But the Service Reference dialog generates like a zillion files. Is there any obscure benefit to VS Service References that I'm missing?
Same reason why you build a .net project with VS and not calling the compiler by hand from command line. The I of IDE stands for Integrated, it does things for you so you do not need to do those things manually from many separated places and procedures.
There is usually a way to do many of those things by hand or with a text editor and command prompt but lets be productive :-)
If you also own the service, I'd say don't use either one. Instead, break up your contracts, entities, and client proxies into different assemblies that you can use both on the service and the client.
Kinda like described in WCF The Manual Way... The Right Way.
I'm trying to use Visual Studio 2010 to Add Service Reference to a service that I do not own. It does not add anything to the app.config, and the Reference.cs file that gets created only contains two classes, viz SerializableExpression and an empty InterLinqType class. But I don't have a usable client that I can instantiate.
When I turn off the option to Reuse Types in generated assemblies then it generates a bit more members in the above-mentioned classes, but still I have no usable client class that I can instantiate as my proxy to the service!
Using Visual Studio 2008 to add a Service Reference to the same service all works perfectly!
Please help.
I've had this issue in the past working with a 3rd party service.
3 things to try.
Download the WSDL locally and try to add it from there.
Create the proxy from the command line and then add it to your project. Here is more info on the command line util: http://msdn.microsoft.com/en-us/library/aa347733.aspx Play around with the flags that are available. Keep an eye on the /targetClientVersion flag. Here is a sample usage:
svcutil /t:code /language=VB http://servicedomain/serviceurl /out:MyServiceProxy.vb /config:MyServiceProxy.config
Validate the WSDL you are looking at is actually valid. I've had invalidate characters, unclosed tags, and invalid locations of extra dtd files throw off the creation of proxies. You can try and use the validator here to see if it fails here: http://xmethods.net/ve2/Tools.po
This is an old post but thought I would added my two cents on my solution.
I had the same issues as well. What I discovered is that my assembly references where not set correctly.
Issue: My test container is referencing my service reference and was only displaying my contracts not my service methods.
Resolution: I was referencing the assembly that contained my contracts. Once I removed it the references reappeared. Then I became curious and wondered if I could reference that assembly if needed without loosing my service reference. So, I readded that assembly I had removed in my references and then right clicked on the service reference and selected, "Configure Service Reference". I chose "Reuse types in specified referenced assemblies" and then only selected the system assemblies - i.e. did not select the assembly that is used in my service and referencted in my test - the only I originally removed to fix the issue. Every thing worked.
Summary: you have to play with the references a bit. This is how I fixed the issue in my project.
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.