I am not quite sure how to ask this questions, so please forgive me for my ignorance.
I have a ASP.NET Web Application and I have as part of this solution a Project that contains all my library of functions and such. So, for simple explanation, I have two projects in one solution. One is a WEB Application and the other is a Project that gets compiled as a DLL and used within the WEB Application.
Inside my Library, I use GrapeCity Active Reports and a few other libraries that I have purchased and licensed. I have created references in my Library and I call those functions to generate reports and stream them. The WEB Application knows nothing about these controls, how they work or anything. So, lets say I call a function GetReport() that will generate the report and stream out to the client as a PDF.
My Library has the LICENSES.LICX with all the necessary license information in it.
The question is this. Do I have to include the license information in the ASP.NET Application, or will it become part of the DLL and I don't have to worry about the ASP.NET Application?
Thanks
as far as i know the caller assembly/exe of the component should have license embed to it you can refer to this link or this link that show and tell you more about it.
Related
I would like to use Excel functionality from a browser. I currently have an excel based Microsoft office application. It adds an icon to the ribbon and does C# based custom application logic to communicate to a database server.
Since it requires application releases for any changes in the schema I am curious if I can convert this into an web application and still benefit from Excel's built in functionality.
I am expecting this to be possible since Microsoft Excel Online is run inside a browser. My question is, is it possible to add plugin to such online excel document? If yes, any example would be much appreciated.
You absolutely can, and depending on approach you can do so with nothing more than a VSTO project template. This is little more than a ClickOnce application. This can launch a browser within a window to perform the logic.
You may use the Office Interop assemblies to decouple your application from Office apps, yet still communicate easily. Make sure you set Embed Interop Assemblies to true once added as a reference.
For those using Office in the browser, it seems as though Microsoft is shifting into CSOM/JSON/REST, meaning this solution is coded entirely differently than COM. This should help you get started:
https://msdn.microsoft.com/EN-US/library/office/dn268594.aspx.
We have a corporate website with a large amount of dynamic business application pages (e.g. Shopping Cart, Helpdesk, Product/Service management, Reporting, etc.) The site was built as an ASP.Net Web Application Project (WAP). Our systems have evolved over the years to use .NET 4.5 and various custom business logic DLLs (written in a mix of C# and VB.NET). However, the site itself is still using VB.NET Web Forms. We now have done a few side projects in MVC 4 using Razor/C#, and we want to use this framework for new pages on the main corporate site going forward. What would be the easiest way to achieve this?
I found this nice list of steps to integrate MVC 4 into an existing Web Forms app. The problem is that because our existing app is a VB.NET WAP, it compiles into a single DLL, and .NET allows only one language per DLL. The site is way too big for us to contemplate converting it to C# all at once (yes, I've looked at the conversion tools, and they're good, but even 99% accuracy would leave us a huge amount of cleanup work.)
I thought about converting the existing WAP into a Web Site Project (WSP) which does allow mixing languages and then following the steps above, but after a few pages of Google results, I couldn't find any steps for converting a WAP to WSP. (Plenty of sites offer the reverse steps: converting a WSP to a WAP.)
Another idea I had was to create a completely separate MVC project, and then somehow squish them together into the same folder structure, where they would share the bin folder but compile to separate DLL's. I have no idea if this is possible, because certain files would collide (e.g. Global.asax, web.config, etc.)
Finally, I can imagine a compromise solution where we keep all the MVC stuff in its own separate application under a subfolder of the main solution. We already use our own custom session state solution, so it wouldn't be difficult to pass data between the old site to the new pages.
Which of the ideas above do you think makes the most sense for us? Is there another solution that I'm missing?
After some more research and experimentation (and thanks to a suggestion from T.S.) I have narrowed it down to either the 2nd or 4th option from my initial question:
Convert our WAP to a WSP, and then follow the steps to integrate MVC into the site. I don't see moving from a WAP to a WSP as a complete step backward. As the MSDN link explains, performance does not suffer, and it's mainly a question of how to adjust our build/deployment process. The major advantage with this technique is that it allows multiple languages to coexist in the same project and root folder. Certain files, such as Global.aspx.vb, would have to remain in VB.NET. But specific folders and web pages could be designated as C#. The disadvantage for us is that our site has a lot of legacy pages that use old-style server-side-includes of ASPX page fragmets, and these cause build errors in a WSP. These would have to be changed into User Controls, or perhaps renamed to an unrecognized extension, such as .aspxinclude, so that they are not included in builds.
Create an MVC child application as a new .NET project (see http://support.microsoft.com/kb/307467). The parent web.config needs its <system.web> section wrapped with <location path="." inheritInChildApplications="false">, and the new app's subfolder needs to be converted to an Application via IIS Manager. The child app can be a WAP using a different default language (C# vs VB.NET). This makes it is easier to isolate from our existing project. But this is also a disadvantage because the MVC routing only works on URL's in the subfolder of the child application. So if we wanted multiple parts of our site to use MVC routing, it would require separate child projects, e.g. (/cart, /myaccount, etc.)
We are probably going to go down the path of option #1, converting to a WSP, and only resort to #2 if we encounter a big obstacle.
UPDATE: I was able to do the conversion using technique #1. It's been working for several months now, so I published a blog post with the procedure I followed.
Came up with a very simple solution.
Create new MVC C# project
Add the old vb project to the solution.
Move the VB aspx pages to the new C# project
REMOVE THE CODE BEHIND ATTRIBUTE FROM THE FIRST LINE OF THE VB PAGES eg...Codebehind="ProductDetails.aspx.vb" (this is the magic)
Add a reference to the VB project in the C# project
This will work for master pages as well
Strangely the VB aspx pages 'just find' the codebehind from the reference and the C# project does not seem to care about the aspx pages being VB.
Go figure!
Hope I saved someone some time. I spent many hours on this.
You have 3 options here:
Convert the ASP.NET Web forms from VB to C#
Convert your MVC 4 written in C# to VB.
Develop all old apps in ASP.NET Web forms again to MVC 4 (ugly but better for future changes)
My advise is keep them diferent projects only share your business logic. And in the same solution file.
This post is really more of a discussion if this is even possible.
There are numerous examples all over the web, but all of those are using asp.net applications and unfortunately I can't go that route. So my goal is to build an upload utility in Silverlight that can be deployed as a CRM 2011 web resource, without using anything Asp.Net related.
I have looked at the Telerik SL upload control, but it appears to require a ServiceURL handler and I'm not sure I can embed something like that within Silverlight and make it work?
I guess I'm looking for some direction here on what my options would be. I don't want to start down one path and run into a brick wall.
Thanks for reading!
Your SL control can upload the bytes of the file as an attachment (in the Notes area) to the entity record. Here is a project on CodePlex that uses SL to upload an image as an attachment:
http://crmattachmentimage.codeplex.com/
Hopefully that will get you pointed in the right direction!
I haven't really looked into the creation of web-resources from silverlight, but considering the web-resource utility would be using the CRM SOAP end-point, I imagine you could do the same from Silverlight.
From Silverlight, you would either need to make a reference to SOAP End-Point url which can be found in the CRM client in Settings -> Customization -> Developer Resources.
Otherwise, you could use the open-source project CrmSilverSoap library which already has all the generated proxy classes as well as a few helper methods for connecting to the various CRM services.
In trying to work with and create the web resources, I'd have a look at the this SDK article which shows to how to use some messages for Creating Web Resources. You will need to make the required modifications to code to enable these messages to be sent via the reference soap end-point in silverlight.
I'm currently investigating SharePoint for our company as a means to make Excel processing accessible through our web application without relying on the Office Interop DLL files. (our sysadmin doesnt want to install Office on the production server, for good reason)
I'm aware that Sharepoint has an Excel Webservice that can be enabled and used by the application. The problem, if it is a problem, is that I need to make a class that wraps all the logic for transforming an Excel into HTML.
So I need to add the references to this webservice to the application.
But what if we need to deploy the application with a customer that has no SharePoint server available, will this cause a problem in the application? We will use checks to make stuff visible and invisible depending on whether a parameter is set, but I'm looking for a means to ensure that I can for example add the required references at runtime when I need them for Sharepoint.
I hope the question is clear.
I'm not sure I understand you completely, but if you're just wondering about changing the URL of a web service(From say http://companyA.co/service.svc?wsdl to http://compB.co/serv.svc?wsdl), depending on where it is, that's easy as pie in .Net, basically just:
service.URL = "http://localhost:51112/Service1.svc?wsdl";
We have a bunch of user controls we would like to pull out of a web application and into a separate assembly/library, and I thought it would be as simple as creating a class library and pulling the ascx and ascx.cs files into the project, and compiling a DLL to be reused among our applications.
This was not the case, however.
Our ultimate goal is to have a single distributable DLL (similar to how Telerik distributes their controls) that we can throw into any web application. The steps here: Turning an .ascx User Control into a Redistributable Custom Control were very simple to follow, however this results in many files named controlname.ascx.guid.dll, which is not the desired result. I couldn't even get these to work anyways, since we have additional classes that need to be compiled into the assembly.
Has anyone successfully created a web user control library in .NET (we're using 3.5 here)? I can't seem to find a nice step-by-step guide.
I realize this is an old topic, but if anyone is looking for a solution for creating reusable user control libraries, it turns out it's fairly simple. Here are two good step-by-step guides along with source code:
From MSDN: Turning an .ascx User Control into a Redistributable Custom Control
From Code Project: Straight way to create ASP.NET user controls library
The second link provides a solution to the multiple dlls created by the first link.
Edit- (2) Seems to be a dead link. Here's the new link
https://www.codeproject.com/Articles/30247/Straight-way-to-create-ASP-NET-user-controls-libra
If you want to share controls among project, my experience has shown that the best way is to build custom asp.net server controls instead of usercontrols. User controls are good for sharing within the same project, but not over multiple ones.
For this purpose I suggest you to build a set of custom server controls inside a class library and use that on all of your projects.
This book does quite a good job at explaining the basics of creating server controls
Edit:
I'm currently developing a .net web server control library. I actually didn't follow any step-by-step guide. I mostly considered using the book I mentioned above and the MSDN library + Reflector, which is a great tool for inspecting existing MS server controls and learning from them.
I found the tutorial Creating and Using User Control Libraries but it seems like a bit of a hack as it relies on a post-build command line event to copy the user controls from one project to another.
Somewhat late, I admit.
To create a re-usable library of user controls; create a new Web Application Project, delete all the scaffolding, add a (number of) user control(s). Create a Web Deployment Project from the Web Application Project, in the WDP properties choose the option to Merge all control output and assign a name for the library and ensure that Allow this website to be updatable is NOT checked.
Build the WDP and use Reflector to examine the generated library; you'll see that it contains an ASP namespace and the types you carefully crafted have been renamed i.e. usercontrol_ascx. In your target website(s) add references to BOTH the output dlls from your WDP, add a system.web/pages/controls node to web.config using the namespace ASP and the name of the assembly that you defined in the WDP.
Now when you use the library in a page (for example) you must use the alias that you defined in web.config and the typename as seen in Reflector i.e.
<ucl:usercontrol_ascx ... />
I found it useful to add a dependancy for the website(s) on the WDP so that the WDP is built before the websites; now I can change the user controls in the WAP without having to remember to build the WAP before building the website(s).
I hope that someone finds this useful as it cost me a few grey hairs getting to this stage and still have VS do its 'automagically' thing.