We are using usercontrols in c# to have separate classes for features inside a tabm which works perfectly.
Our problem arises, when an usercontrol uses a Service Reference to any Webservice.
The first time dragging the control on the form works. The second time, the designer will show an error:
Could not find default endpoint element that references contract 'testSR.WebService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
The app.config contains the correct endpoint and it works as long as the calling code is inside the form itself, as soon as we move the code to the usercontrol, we have these problems.
I even tried to put the user control inside another project within the solution referenced it correctly and copied the endpoint/binding configurations from the app.config of the DLL to the EXEs app.config - then also the problem arises again...
It seems that user controls cannot reference webservices, but there should be a solution!?
EDIT: From my testing it now seems that user controls can use service references, but the VisualStudio Designer will only work for the first time, after that the programm still works, but the designer shows the error and when I ignore it, the designer removes the user control from the form. As long as I do not touch the containing form, the usercontrol is editable and working fine ...
I assume you are working with winforms. have a clear separation between UI and WCF and avoid this and other issues by making the usercontrol not to call wcf directly but call an intermediate class library which calls the service layer for you. In this way the WCF will be called by such class library and your UI will be isolated.
Actually thinking about this problem you are describing, are you requiring WCF connectivity at design time as well? if so you shoul probably avoid it by checking if running at design time in which case do nothing. removing the dependency and having your UI independent from Service References is anyway surely a good idea.
Only four years late, but I actually found a fix to the WCF issue when instantiating the service in the usercontrol.
As #DavidePiras stated, make a service class library and reference the binary .dll. (Call the .dll, Worker in this case for my answer)
In your user control, rather than instantiating the Worker class in the constructor, make a new method, call it LoadWorker in this case.
..
private Worker worker;
public CustomUserControl()
{
InitializeComponent();
}
public void LoadWorker()
{
worker = new Worker();
}
--
In your form where you are calling this userControl, but can't see it, then either in another method or in the constructor for the form, call usercontrol.LoadWorker().
--
public MyForm()
{
InitializeComponent()
customUserControl.LoadWorker();
}
An extra step I took from here was to close all open windows/files and do a Build Solution. Then reopen the form that the designer was failing on and it should be good to go.
Cause?
The form that worked at runtime versus what you saw in the designer window in VS20xx has to deal with what is instantiated at the runtime versus what occurs when the designer window is loading your user control. I don't know the fine details or the terminology to necessarily describe it, but that is what is causing it. I have found that throwing the loading of the WCF service into a separate method to be the easiest solution.
I hope it helps anyone else who runs by this answer now.
Related
I'm working on a Visual Studio solution that currently has two projects in it (with more to come later). One project is a mature C#/Winforms application that I built last year (think of it as the prototype). The other one is a DLL that is going to do the same thing as the prototype but through a different application. I'd like to re-use code from the prototype (let's call the method in question SyncInvoices() ) in the DLL because the prototype code works perfectly b/c I've hammered the bugs out of it. The class that contains SyncInvoices is baked into the prototype application instead of being its own DLL.
I've added the class that contains SyncInvoices() to the DLL's project (as a linked file, since it already exists elsewhere in the solution). I can instantiate that class in the DLL project and call SyncInvoices() but the compiler throws errors related to GUI elements.
The problem is that SyncInvoices() has some-thread safe calls to the Prototype application's GUI in it, basically used to pass messages/errors back to the interface.
The DLL doesn't have a GUI, so it doesn't need to run that code. It still builds the rest of the methods in that class, even though they aren't used. Is there a way I can tell the compiler to ignore those lines when building the DLL? I'd rather not maintain two sets of nearly identical code, especially when the two projects are part of the same solution.
I thought about using #define/ #if blocks to partition off the code but I'm not sure if C# works that way-- most of the time I've seen those used is to keep debug code from ending up in production. If it is possible to tell the app to include/exclude code through #if blocks, how do I set the values?
Should I just bite the bullet and make a copy of the method without the offending code in it?
Without more specifics it's hard to give the correct answer, but I'd say generally you'd handle this with events. Whatever calls into the GUI are happening in the prototype, that would typically be some form of event, which you would subscribe to in the prototype when you instantiate your new class.
Are there any particularly problematic cases you could give more specifics on?
I have 3 projects: UI, Core and Host, windows forms, class library and windows forms respectively.
UI is my startup project but the setting for Start external program is Host.exe.
UI has a reference to the Core project which is my data-access layer.
Host is the one loading the configurations.
Basically, when I run the application, the first thing that is executed is the Main function of the Host project.
Now, within the Main function, I'd like to get data from the database but Host has no reference to Core.
How do I get data from the database when my Main function is executed?
Currently, what I can think of is execute something (batch file or tt) on my Main function and write to a file. From the file, I will get my data. Can you suggest other ways to do this?
If Host has reference to UI you can create a public class / method in UI which host will be able to consume.
if UI has a reference to Host and Host has no reference to UI, you could still do something like that by using interfaces, say you add another project called "Interfaces" and in there you create an interface "IProvideDBAccess" for example, host will reference that assembly.
UI will contain a public class which will implement the interface "IProvideDBAccess" and host will be able to use any object retrieved at run-time which implements that interface even with no strong reference to UI.
of course there are many other way to accomplish what you would like to do surely without saving a text file and parsing it again ;-)
Have a look here as well for some project or solution layering ideas, just as ideas I know it is not totally what you are looking for in your specific case: https://stackoverflow.com/a/7474357/559144
I'm trying to implement Blackjack via Visual Studio, but have just been introduced to it. Suppose I have a PictureBox representing a card in a hand. This box starts with an image of a face-down card, representing a card slot that hasn't been dealt to yet. I have a function in my Form object that changes the PictureBox image to another card image resource based on an integer parameter. This is all pretty standard.
What I'm having trouble with is actually calling the method from main. I could create a new Form object and set the auto-generated one to invisible, but I'd rather work with the form that's auto-generated. Should I just put all the game logic in the Form1.cs file? Does the auto-generated form object have some default name I can use?
I realize this seems pretty novice level, but it seems like Microsoft's support documentation would prefer you create entire projects from the designer view and doesn't help much for actually coding.
The typical model for a simple Forms program is to allow the Main() method in Program.cs to remain in its default form: set some things up, create an instance of your primary Form subclass (the class name by default will be Form1), and pass that to the Application.Run() method.
It is good design to have a "controller" object outside of the UI object. But especially if you are starting out, you may well find it simpler and easier to understand if that "controller" logic is also in your primary Form subclass.
In that case, yes…all of the code winds up in the one .cs file, and indeed in the one object.
Even with the controller logic in the Form object, you will still find it useful to keep the code that is essentially controller logic separate from that which is user-interface logic, and to use the C# #region directive to label these sections of code. That will help you keep a mental model that still separates the two roles within the same class.
Beyond this, there are lots of differing opinions, from the complete "shoot-from-the-hip" approach, to the extremely strict and rigorous adherence to specific design patterns. But the above is consistent with the pattern that the Visual Designer leads you to, and so is a fine place for beginners to start.
I have an small application that I have written that needs to be used/incorporated into about 6 larger pieces. Ideally I want to be able to open this smaller piece from each stand-alone application instead of adding the code to each one. This would allow for easier maintenance in the event there are changes they only need to take place in one application.
I have looked but I can't seem to figure out how I can open a second winform application from inside of one. Any help would be great.
Thanks
2 options.
1) If this small app can stand alone, meaning it can execute in some useful fashion without being spawned by a parent app, then use Process.Start(). Your application(s) that spawn this process may not be able to run in a partial-trust environment.
Process.Start("notepad.exe");
2) If the app is only useful within the context of the parent apps, say by being given objects or other arguments from the other apps, consider refactoring the small app to allow the form's project to be referenced by the parent apps. Then, your parent apps can simply create a new instance of the form and display it:
var childForm = new SmallAppForm();
childForm.Owner = this; //the child window will close when its owner does.
childForm.Show();
Though it's more code, it's generally easier and more foolproof to implement. The form can also be accessed and thus controlled from elsewhere in the app, and other functionality can be implemented without having to deal with the rather messy business of cross-process communication.
I'd look to make this a Library that's a separate project that you add a reference to from your other projects. Much cleaner than spawning child processes.
I've followed the instructions in this MSDN article: http://msdn.microsoft.com/en-us/library/dd206945.aspx
Is it possible to call a method that is in the myWebPart.cs file, from the MyUserControl.ascx file? I don't seem to have intellisense of the methods in the myWebPart.cs unless I do:
myWebpart mywbprt = new myWebpart();
mywbprt.myMethInWebPartcs();
However that gets the error, and does not compile:
Error 2 'myWebpart' is a 'namespace' but is used like a 'type'
The myWebPart.cs and MyUserControl.ascx share the same namespace, and I thought that would be enough to call the methods in myWebPart.cs in the usercontrol, but apparently not?
Am I missing some intricacy of SharePoint?
First of all, it looks like the namespace that myWebPart is in has the same name as the web part. You should change that. You will then probably not have the compile-time error.
You will have a runtime error. If this method you want to call interacts with the runtime state of the web part, then it should not be called from outside the web part, most likely.
More to the point, the user control needs to find and call on the particular instance of the web part that is currently active, not create a new instance, which will have nothing to do with the instance that was already running.
If the method is a static method (or if it should be), then this makes somewhat better sense, but I would argue that such a method does not belong inside the web part. It should be moved to a class library shared by the web part and by the user control.
I agree with what John says, and I'd like to add the following...
If your user control is contained within your web part, you should be able to use the Parent property and go up the hierarchy to find it. Another way of handing communication between the two would be to register for events from one to the other.