I am trying to put together a winform app that also has a web interface that can interact with events generated from within the winform portion of the app. I am successfully running the cassinidev server from within the app and asp.net pages are being processed but I am still running into a few obstacles and I am not sure if they are even possible???
I am unable to use code behind pages. I have added the appropriate
attributes to the page directive but I still cannot access controls
from the aspx page.
I am unable to access classes from the web portion of the app. See
screenshot...
Maybe what I am trying to accomplish is not even possible but if anyone can help to point me in the right direction I would be most grateful!
I'm pretty sure you can't do that since the only thing you have available is the "website path" option.
You do however have the source and if you find some way of sharing data (maybe using the ApplicationPool) you could probably do that...but i'm guessing you'd still need to cast that data on startup to a static variable in your website.
Seems like too much work 2 me.
I'd suggest selfhosting WebApi as well and then just using that as the data layer of your website.
Both can be hosted in winforms and webapi CAN share static data directly from your code :)
Related
i have just went through this article to create a web application with multiple web application.
https://support.microsoft.com/en-us/help/307467/how-to-create-an-asp-net-application-from-multiple-projects-for-team-d
my requirement exactly match this.i have a large web application which i have to deliver in multiple phases and when deploying the changes of any child project,it should not affect the existing running child project or main project.i should be able to use the use control or dll between the child projects.
i need a sample of this approach. i have tried to create the same but the sharing of user control etc. between the child projects is not working.i think ,i am doing something wrong. if anyone have a sample or example of this approach then please share.
i am working on asp.net web form application not MVC.
Presuming you are using source control effectively, this should not present any problems. You can add a child project at any time and keep it checked out to yourself. When you are satisfied with unit testing you can perform integration testing before putting it live.
The only issue I see with your description of the problem lies with attempting to share User Controls between projects. People have been experiencing problems with this approach for a long time, especially with the Web Site Template. It apparently is possible for Web Forms projects:
How do I share user controls between web applications in ASP.NET?
Creating and Using User Control Libraries
Personally, I think it depends on what you are trying to to with the User Controls. For example, are they just displaying something that is repeated on different pages? In that scenario, make more judicious use of Master Pages. If they are being used for functionality, then consider the creation of a library of Custom Server Controls and reference these in your projects?
I wanted to build a VB.net web application using MS Visual Studio 2015. Someone suggested me to create a Web API instead of MVC project if i'm also planning to create a mobile app later on. I may use angularjs in my project so controllers will surely be used, so what should i choose when creating the project in the first place?
Because when i created a web project: File=>New Project=>ASP.net Web Application=>Empty..there are no folders for Controllers, Model, etc. Do i have to create a Controller folder on my own?
Or should i do this: File=>New Project=>ASP.net Web Application=>Web API..? sorry if its a silly question. its just that i'm afraid that if i chose the wrong project now, it'll affect the development later on.
Answer to your question mainly depends on your choice and needs,
for example
In Case of an empty project as name defines you will have nothing else web.config.
Benefits of it:
here you can define, design your own structure. you can either make
it simple 3 tier or you can make it WEBAPI application. it's all up
to you.
however in the case of choosing Webapi template you will have a prebuilt structure which can help you out for initial understanding
https://docs.asp.net/en/latest/tutorials/first-web-api.html
benefits of it
You will get predefine template and structure.
you can utilize of webapi's which further isolate you backend logic from the frontend.
as you are also planning to create the mobile app. and using front end as angular, so in that case, webapi may come handy.
as the whole world is moving towards webapi, so i will recommend you to use it. please refer https://blogs.msdn.microsoft.com/martinkearn/2015/01/05/introduction-to-rest-and-net-web-api/
so down the line it all depend on you if you want to build you application for the stretch and take full control of it regarding structuring backend etc.. then go with empty else go with Microsoft pre-define template
Thanks,
Ajay Kotnala
I was recently asked to create a web page using a static website generator, like Jekyll. My question is this:
How does this differ from just creating a website using HTML or writing the page as an ASP.net project in Visual Studio?
How does it work on the server?
What are some concerns I should have?
I'm a .net guy, so I would like to be able to create this in visual studio, if possible.
Here are some advantages and disadvantages that came to my mind:
Advantages
can be deployed on every server, as it's just static html
has partials, that can be reused, in contrast to normal html, where you have to code/copy paste every thing
you can still code in an IDE
a non developer can edit code (sometimes at least)
Disadvantages
the template language is limited and sometimes a bit awkward/needs to get used to
you have something new in your environment, which has additional costs (more than one developer needs to know how to build the site, ...)
If you know your current toolkit well and you do not have a problem hosting another ASP.net project on your server, I do not see the need for you to introduce another tool in your tool chain.
If you want to do something, where users can generate content - like github does on the github pages - this is something you might consider.
As for Jekyll, we tried it on one project and being devs, who like to code, we ran into it's limitations quite early. You can work around this, but if you know a programming language you will be faster. It was still fascinating, how far we were able to go with just using Jekyll
With ASP.NET pages exist throughout the life cycle of the page, and able to work with request and session context. See this article asp.net page life cycle
HTML pages are static and you can not access any variable that is on the server.
I recommend you follow the step by step this link to go to just understand how to develop ASP.NET http://www.asp.net/get-started
I hope that helped
Vicente
I have a ASP.Net web application that I want to use as a reusable user control library in other web applications.
One solution for this problem is to use what Scott Guthrie has described here:
http://weblogs.asp.net/scottgu/archive/2005/08/28/423888.aspx
that is to copy ascx/aspx files (without their code-behind) in the web applications which use the control library.
I actually see another solution: to embed the ascx/aspx in the User control library and then use a custom virtual path provider to get them.
Does anybody know which solution is the best ?
From the deployment point-of-view, the virtual path provider seems to be better.
However the 'ascx/aspx copy' solution is easier to implement (no need to create a custom virtual path provider).
I really do not like Scott's solution. I believe it is ungly and creates overhead that is not necessary. I have also seen something similar in action and it just didn't work for me.
I too had the same requirement as you describe and I used the virtual path provider option. This way I could reuse all my user controls between web applications easily and without work arounds.
The virtual path provider has a couple of issues though:
If your ascx file has any server tags (in javascript or any other place for that matter) that cause an issue you will get a run time error that is not that helpful.
You have to rebuild your application every time you do a change to the ascx's mark up or to Javascript that exists on the file it self in order to see the results. That can be a real pain if you are trying to change the design of an existing control.
I have used the solution as described in this article and it worked very well:
http://www.codeproject.com/KB/user-controls/EmbeddedUserControl.aspx
I hope that helps...
I ran into this same situation a few weeks ago and I could not make Scott's solution work. I instead used Custom Server Controls and put those in their own Class Library.
I really don't think its a good idea to use user controls that way. If you need them in a separate library, you should convert them to server controls.
Our team is trying to figure out some guidelines for using pagemethods vs. creating an actual asmx web service. Seems to me that pagemethods are primarily for one off type calls that are specific to the page, where as asmx are intended are intended represents more of a reusable set of operations and services. Does this sound correct?
Yes. If yo intend to have something thats going to be used by multiple application it is wise to create it as a separate service, so you are not repeating code between applications and also if have to change you change in a single place.
Simple example,
If you have lets say a authentication need, and you have 2 app, one web and one windows.
If the user base is going to be the same, it does not make sense to go in the Web App create an authentication code/page, the go to you windows app, and do the same all over again. The reason is, what if have to change the hash code for exemple, you would have to go to the web change it, then go to windows change it, and also redeploy window, now
if you have a service, you go to the service change it, and everything now works with the new model, and a big plus, you don't have to redeploy the windows app.
Thats all folks...
Even if you're only working on one page and the functionality in question is only used on that one page, sometimes it's better to move the functionality to a separate web service for performance. i recently worked on a page that would make hundreds of calls to a single page method. i noticed a huge increase in performance when i moved it off to a web service simply because you're not dealing with the entire lifecycle of the page. if you're doing something small though, use page methods to keep everything simple.
Update: ArmedMonkey is correct and page methods do NOT go through the page life cycle.