Does anyone have a nice way to search through a WebForms web app to return the list of unique user controls used throughout the app (in .aspx and .ascx pages)? We've got 100+ pages and 150+ user controls. We are also using a few third party libraries and I want to see which controls we are using across the app. I'm not necessarily looking for a count of each unique control, just the unique items. For example: asp:Label, asp:MultiView, etc.
Thanks in advance.
I'm using NDepend when it comes to dependencies analysis and changes analysis. If you don't have licence trial version should allow you to use all features without restrictions.
Start from creation of the new project and add compiled assembly of your web application. It will automatically load all dependencies which you can browse with Class Browser. This will give you the basic understanding of what types (controls) are used by your web app.
Also you can narrow or extend your findings with Queries and Rules Edit (Ctrl+Alt+R). Run following query to get a list of used controls from System.Web.UI.WebControls:
from type in Assemblies.WithNameNotIn("WebApplication2").ChildTypes()
// depth is needed th find all controls that are used directly or indirectly
let depth = type.DepthOfIsUsedBy("WebApplication2".MatchAssembly())
// we are interested only in types from specific namespace, in this case "System.Web.UI.WebControls"
where type.ParentNamespace.Name == "System.Web.UI.WebControls"
where depth >= 0 orderby depth
select new { type, depth }
As you can see query result could be exported various formats (HTML, Excel, Text or Graph).
NDepend is very powerful tool mostly because of built in Code Query Language. It is based on the LINQ and you can start creating simple queries without any additional training or learning.
Related
I am new to Google App maker and I don't have a lot of experience with coding either (sorry :/). Since App maker is marked as low-coding app builder tool, I assumed it was not that hard to make a very simple app with it. However, for me it is.
I need to make a simple app for demonstrations purposes only (so Cloud SQL and other complex database solutions are not in my interest here). I want to make it using calculated models (correct me if I am wrong, calculated models are just temporary solutions, since apps need to have like real databases to be fully functional?).
My app is basically made of 2 datas: 1) Employees and 2) Departments
-> Fields for "Employees" are: First name, Last name and Department.
-> Field for "Departments" is just Department name.
My app is supposed to look like this:
1st page: Table with current employees that has a button to add new employee,
2st page: Table with all department names (e.g. marketing, finance...) that has a button to add new department name,
3rd page: Form that opens when I click on add new employee button in which I can insert their first name, last name and from drop down menu choose department,
4th page: Form that opens when I click on add new department button in which I can insert new department name.
5th page: Form (or some other widget, not sure here) that has option to insert first and last name in order to find out what department that employee is assigned to.
I tried to make first 4 pages, but I end up with forms that I cannot insert anything into them. 5th page is still too much for me.
I hope you understand my struggles and if you know how to do it please share your knowledge. Thank you very much!
Calculated models are kind of like SQL views - they are not necessarily for temporary solutions. Every time you load a calculated model the script you write under that model's datasource is ran. That script usually loads data from an external source (I.e. grabbing stock prices from an API, loading data from an external SQL server, or generating random placeholder data).
You could use the cloud SQL models for this application that you are building - your table with all department names that is supposed to be displayed in the second page could just be a cloud SQL table with one single field for a department name.
I suggest you work through the example apps so you can get a better understanding of how the different components work. Here is a link to one for you to get started.
In short, you're going to create a few models to store information (I suggest using cloud SQL as the calculated models will require code whereas cloud SQL is more plug and play through app maker's bindings). Before you create any pages try to lay out how your databases will look as that will dictate how you set bindings or program your scripts.
Asking to completely make what is essentially a combination of the tutorials already provided by Google is pretty counter intuitive - you should ask more specific questions in regards to implementation.
As for App Maker being a low-code environment, that's only partially true. For very, very simple apps (think glorified forms) you will need only a couple lines of code and can probably do everything through drag-and-drop. However, anything more complicated than a simple form will almost certainly require a good chunk of actual code. There are plenty of resources online to learn Javascript.
You might want to try a google partner like AppSynergy for building stuff like this. It might be overkil for what you need (or maybe not if you intend to build a lot more stuff).
If this question is deemed inappropriate because it does not have a specific code question and is more "am I barking up the right tree," please advise me on a better venue.
If not, I'm a full stack .NET Web developer with no SSRS experience and my only knowledge comes from the last 3 sleepless nights. The app my team is working on requires end users to be able to create as many custom dashboards as they would like by creating instances of a dozen or so predefined widget types. Some widgets are as simple as a chart or table, and the user configures the widget to display a subset of possible fields selected from a larger set. We have a few widgets that are composites. The Web client is all angular and consumes a restful Web api.
There are two more requirements, that a reasonable facsimile of each widget can be downloaded as a PDF report upon request or at scheduled times. There are several solutions to this requirement, so I am not looking for alternate solutions. If SSRS would work, it would save us from having to build a scheduler and either find a way to leverage the existing angular templates or to create views based off of them, populate them and convert that to a pdf. What I am looking for is he'll in understanding how report generation best practices and how they interact witg .NET assemblies.
My specfic task is to investige if SSRS can create a report based on a composite widget and either download it as a PDF or schedule it as one, and if so create a POC based on a composite widget that contains 2 line graphs and a table. The PDF versions do not need to be displayed the same way as the UI where the graphs are on the same row and the table is below. I can show each graph on its' own as long as the display order is in reading order. ( left to right, then down to the next line)
An example case could be that the first graph shows the sales of x-boxes over the course of last year. The line graph next to it shows the number of new releases for the X-Box over the course of last year. The report in the table below shows the number of X-box accessories sold last year grouped by accessory type (controller, headset, etc,) and by month, ordered by the total sales amount per month.
The example above would take 3 queries. The queries are unique to that users specific instance of that widget on that specific dashboard. The user can group, choose sort columns and anything else that is applicable.
How these queries are created is not my task (at least not yet.) So there is an assumption that a magic query engine creates and stores these sql queries correctly in the database.
My target database is sql 2012 and its' reporting service. I'm disappointed it only supports the 2.0 clr.
OI have the rough outline of a plan, but given my lack of experience any help with this would be appreciated.
It appears I can use the Soap service for scheduling and management. That's straight forward.
The rest of my plan sounds pretty crazy. Any corrections, guidance and better suggestions would be welcome. Or maybe a different methodology. The report server is a big security hole, and if I can accomplish the requirements by only referencing the reporting names paces please point me in the right direction. If not, this is the process I have cobbled together after 3 days of research and a few msdn simple tutorials. Here goes:
To successfully create the report definition, I will need to reference every possible field in the entire superset available. It isn't clear yet if the superset for a table is the same as the superset for a graph , but for this POC I will assume they are. This way, I will only need a single stored procedure with an input parameter that identifies the correct query, which I will select and execute. The result set will be a small subset of the possible fields, but the stored procedure will return every field, with nulls for each row of the omitted fields so that the report knows about every field. Terrible. I will probably be returning 5 columns with data and 500 full of nulls. There has to be a better way. Thinking about the performance hit is making me queasy, but that was pretty easy. Now I have a deployable report. I have no idea how I would handle summaries. Would they be additional queries that I would just append to the result set? Maybe the magic query engine knows.
Now for some additional ugliness. I have to request the report url with a query string that identifies the correct query. I am guessing I can also set the scheduler up with the correct parameter. But man do I have issues. I could call the url using httpWebRequest for my download, but how exactly does the scheduler work? I would imagine it would create the report in a similar fashion, and I should be able to tell it in what format to render. But for the download I would be streaming html. How would I tell the report server to convert it to a pdf and then stream it as such? Can that be set in the reports definition before deploying it? It has no problem with the conversion when I play around on the report server. But at least I've found a way to secure the report server by accessing it through the Web api.
Then there is the issue of cleaning up the null columns. There are extension points, such as data processing extensions. I think these are almost analogous to a step in the Web page life cycle but not sure exactly or else they would be called events. I would need to find the right one so that I can remove the null data column or labels on a pie chart at null percent, if that doesn't break the report. And I need to do it while it is still rdl. And just maybe if I still haven't found a way, transform the rdl to a pdf and change the content type. It appears I can add .net assemblies at the extension points. But is any of this correct? I am thinking like a developer, not like a seasoned SSRS pro. I'm trying, but any help pushing me in the right direction would be greatly appreciated.
I had tried revising that question a dozen times before asking, and it still seems unintelligible. Maybe my own answer will make my own question clear, and hopefully save someone else having to go through what I did, or at least be a quick dive into SSRS from a developer standpoint.
Creating a typical SSRS report involves (quick 40,000 foot overview)
1. Creating your data connection
2. Creating a SQL query or Queries which can be parameterized.
3. Datasets that the query result will fill
4. Mapping Dataset columns to Report Items; charts, tables, etc.
Then you build the report and deploy it to your report server, where the report can be requested by url with any SQL parameters Values added as a querystring:
http://reportserver/reportfolder/myreport?param1=data
How this works is that an RDL file (Report Definition Language) which is just an XML document with a specific schema is generated. The RDL has two elements that were relevant to me, and . As the names infer, the first contains the queries and the latter contains the graphs, charts, tables, etc. in the report and the mappings to the columns in the dataset.
When the report is requested, it goes through a processing pipeline on the report server. By implementing Interfaces in the reporting services namespace, one could create .NET assemblies that could transform the RDL at various stages in the pipeline.
Reporting Services also has two reporting API's. One for managing reports, and another for rendering. There is also the reportserver control which is a .NET Webforms control which is pretty rich in functionality and could be used to create and render reports without even needing a report server instance. The report files the control could generate were RDLC files, with the C standing for client.
Armed with all of this knowledge, I found several solution paths, but all of them were not optimal for my purposes and I have moved on to a solution that did not involve reporting services or RDL at all. But these may be of use to someone else.
I could transform the RDL file as it went through the pipeline. Not very performant, as this involved writing to the actual physical file, and then removing the modifications after rendering. I was also using SQL Server 2012, which only supported the 2.0/3.5 framework.
Then there were the services. Using either service, I could retrieve an RDL template as a byte array from my application. I wasn't limited by the CLR version here. With the management server, I could modify the RDL and deploy that to the Report Server. I would only need to modify the RDL once, but given the number of files I would need and having to manage them on the remote server, creating file structures by client/user/Dashboard/ReportWidget looked pretty ugly.
Alternatively, I instead of deploying the RDL templates, why not just store them in the database in byte array format. When I needed a specific instance, I could fetch the RDL template, add my queries and mappings to the template and then pass them to the execution service which would then render them. I could then save the resulting RDL in the database. It would be much easier for me to manage there. But now the report server would be useless, I would need my own services for management and to create subscriptions and to mail them I would need a queue service and an SMTP mailer, removing all the extras I would get from the report server, need to write a ton of custom code, and still be bound by RDL. So I would be creating RDLM, RDL mess.
It was the wrong tool for the job, but it was an interesting exercise, I learned more about Reporting Services from every angle, and was paid for most of that time. Maybe a blog post would be a better venue, but then I would need to go into much greater detail.
I'm trying to show a Sharepoint list on an ASP page that's running on a different server to the Sharepoint site. I originally tried using the Server Object Model, but with no success (see: Using Sharepoint GridViews on server without SharePoint installed)
So I have settled for using the Client Object Model instead. Now this allows me to pull data from Sharepoint, however, and please correct me if I'm wrong, there is no built in functionality that allows you to bind ASP.net data tables/grid views to Sharepoint objects. The ASP.net page runs on a server that does not have Sharepoint installed.
I would very much like to use ASP.net grid view objects, as they're very design friendly (visible in the GUI) and provide a whole host of functionality - sorting, paging, and so on. These objects need to consume ASP data sets afaik (I'm new to ASP.net development), so I've created a data set object, and a data table to source the data from.
These data tables are clearly designed to retreive data from SQL based sources, as the only options Visual Studio provides for populating them is from the various SQL platforms. However I was able to use the GUI to add the columns I wanted to the data table. These column names correspond to columns of metadata in the Sharepoint list I want to retreive from.
Now can anyone provide me with the steps - preferably with regard to best practice, that I need to go through in order to ensure that the grid view is populated with values when the user loads the page. I already know how to access the values via the Sharepoint web service, but I'm just not sure how to get them into the ASP data set.
By making use of the GetListItems method, I can have all the items of a particular list in the form of XML node. All I need is to convert this XML into data set. Here is how you can convert the XML node to DataSet. You can iterate through the xml nodes and create rows to your dataset as shown here.
I am in the process of migrating an Access application to Sharepoint 2010 (Enterprise). I would like to use as much Sharepoint "out of the box" funcationality as possible, but I am not opposed to creating some Web Parts.
I am struggling with the design of the "master" table in this application. The application is used to track employee productivity. Daily, about 50 users access the application and basically enter how many "Widgets" they completed that day. There are about 30 types of these "Widgets" and they don't change very often.
The table is designed with individual columns for each of these Widgets. This makes creating the Reports very easy, since all you have to do is select all the fields from the table and dump the result set.
The downside to this approach is obvikously the fact that the schema is "hard coded" (static). I have been asked (in the sake of time) to just normalize the table as much as possible (with CustomerIDs, EmployeeIDs, etc), but keep all the "Widget" fields in there.
I had proposed that we create a Master Detail type relationship where the users would Add a Row (perhaps in a GridView), select the "Widgets" they created that day (from a drop down) and enter their quantity. They generally only make 1 - 3 types of Widgets per day.
The users hate this design and want me to give them a data entry form with ALL the widgets displayed so they can just click in the box (beside the Widget they created that day) and enter their qty and then click save.
I know I could still create this type of Data Entry Form with a Master-Detail type of relationship, but I am pretty sure I couldn't using the SP Out of The Box forms. I would probably have to create a Web Part with a GridView and just populate the GridView with all the possible Wisdgets, then let the user enter the proper Qty(s) beside each widget they are made that day. Once the form is submitted back, I would then have to go through it and find any Qtys that are valid Numbers and add a (child) detail record for that Master record. (The Master Record would contain date, employee, customer, etc. etc.) The "edit" form would also have to work in a similar way.
This is a pretty "ugly" solution and I was looking for an alternative.
If I can't come up with a good alternative (and convice my manager that the code won't be too difficult to maintain or add too much development time to the project to complete it on time) then I will have to bring over this ugly, existing schema with all its wasted space and have "hard coded" stuff thoughout the application. (For instance, if I provide them with a SharePoint View to see how many Widgets of a certain Type were created, I will have to "hard code" all those values in the Drop Down and "Sum" the correct/matching database column. YUK.
Another consideration is the reporting. Right now all the reports just contain a column on the report for every widget. To preserve the look of these reports (if I use a Master/Detail relationship) will require "fancier" queries (Stored Procedures) to buld the proper result set in a "columuar" format. (And I am not sure how I would tackle laying out the SharePoint Views of the data in a similar fashion.)
It certainly would be "easier" to just leave the schema as is (and have all that wasted space in the table). I just hate developing an application that anytime we need to add a new "Widget" to the application, we have to change the application in several places and rebuild. (Although, my manager isn't concerned about that, he just wants to push it out, ASAP...sigh...)
Any help/recommendations on how to do this type of application (specifically how to create the data entry forms and views) in SharePoint would be greatly appreciated!
Shayne
Have you looked at these ideas:
http://paulgalvinsoldblog.wordpress.com/2007/12/24/implementing-master-detail-relationships-using-custom-lists/
http://blogs.msdn.com/b/alexma/archive/2006/04/10/610934.aspx
In my opinion you should be storing the data in list rather than SQL server. If you decide to use SQL server, look at BCS to build Master child view.
I'm developing a web application which processes invoices(the functionality is not limited to invoices, but it doesn't matter). One of the parts of the workflow is to print invoice after it was published. This means that the website user is able to select 10-20(and more) invoices and print it at once. Also there may be several invoice templates which may be customizable(this is one of the key requirements).
I should also mention that we decide to generate PDFs from the html code and then print it. So as the PDF creation process may take some time to complete we decided to use a windows service for invoices printing.
So, summarizing we have the following requirements:
There should be customizable invoice
templates;
The website user should be
able to specify which template he
want to use with the invoice item
specified;
There should be a possibility to
print one or several selected
invoices in one click.
Our first idea was to use user controls as invoice templates. The user control will be responsible for invoice layout. This also means there will be a base class for these user controls through which we will be able to define a data source for the controls.
In this case we may even allow users to modify ascx file (or something similar) to edit basic captions if necessary.
The problem begins in the windows service where we are unable to generate output for user controls. So the other solution is to use http handler or web service to generate user controls output and transfer this to the windows service. But this complicates the solution (e.g. we need to use authentication for this and similar problems).
Maybe there is a much more simpler way to do it?
Thanks in advance.
In response to your comment, I suggest you have the website generate the HTML and save it into a 'GeneratedInvoice' field in your DB, which the service then processes (i.e. converts to PDF however your pdf conversion software does it). It's appropriate because you have a 'saved' copy of the generated invoice; i.e. if your invoice processing routine changes (different styles, etc) your old invoices aren't affected, and yet you can regenerate a given bunch in a possibly 'new' format if required.