When I first looked at Office Scripts I was thinking it is good for simple formatting. I have an Excel VBA addin (.xlam) engineering app that does estimation and optimization for a product. I'm wondering how extensive an app you can create in Office Scripts. It has interesting opportunities for collaboration. Questions:
Is there a runtime limit for a script? I envision some optimizations taking 20-30 minutes.
Is there a size limit on scripts? My VBA addin is 2500 lines.
Is there a good way to manage large Typescript files?
Is there a runtime memory limit?
Is there a limit on JSON fetch data size/number limits? My addin uses a local Access database to hold engineering data. I envision creating a lot of JSON files from the database.
Is there any way to use GIT or Devops for backing up scripts.
Is there a way to use Visual Studio or VSCode?
It may be a good idea to look into Office.Js add-ins. Office Scripts is built on top of Office.js. You can see the differences here.
Office.js was designed with developers in mind. And it will give you many of the options that you're seeking (git support, use of VSCode, the ability to manage several typescript files, etc.) You can read more about using the Excel JavaScript API within Office.js here.
For your application I would recommend looking at Script Lab. Script Lab will let you prototype and save your prototype to GitHub as a gist.
Is there a runtime limit for a script? I envision some optimizations taking 20-30 minutes.
There is no runtime limit on your local machine.
Is there a size limit on scripts? My VBA addin is 2500 lines.
There is no size limit on scripts. note: scripts are currently limited to a single file.
Is there a good way to manage large Typescript files?
Scripts are currently limited to a single file.
Is there a runtime memory limit?
How much memory are you anticipating your program needing?
Is there a limit on JSON fetch data size/number limits? My addin uses a local Access database to hold engineering data. I envision creating a lot of JSON files from the database.
See the fetch API
Is there any way to use GIT or Devops for backing up scripts.
Not easily.
Is there a way to use Visual Studio or VSCode?
Yes. You can use vscode.dev (The Web version of Visual Studio Code).
Related
I have read very little content regarding Sharepoint (SP), and most of my reading has been sales pitch oriented overview material. I utilitze VBA with Office apps - especially Access - on a regular basis, and I am wondering if there is any translatable way to retain the custom functionality of writing my own VBA within Sharepoint, especially with MS Access.
I have read that Access databases can be run on SP, with tbales to list and forms to InfoPath, but I am assuming they are primarily talking about Access database apps that were built with wizards, which consist mainly of bound objects without explicitly-defined code.
Most of my app are primarily code driven with VBA because of my automation requirements, which I rely on to perform my tasks. Am I going to be able to accomplish the same thing within SP, and could anyone please provide any references on the subject, specifically?
You can use Access to distribute your front end to users, regardless of how much VBA it has, but an app with VBA code in it will not convert to run in the browser as a Web Database within Sharepoint 2010's Access Services. For that to work, you have to use the new, more powerful macros and limit yourself to the features supported by web objects. For an existing app, this means rebuilding every object from scratch.
Do you need to run your Access app in a web browser? If not, then you're barking up the wrong tree here.
AFAIK Sharepoint does not support VBA.
If you publish an Access database to SharePoint as a web database it cannot use VBA, however you can create a hybrid with the tables in SharePoint and the frontend in Access, that way you can have as much VBA etc as you want and still have the advantages of your data being stored in the SharePoint SQL server. You can store the frontend on SharePoint and have users download it through SharePoint .
The alternative is to keep a traditional Access database on the SharePoint share and access it via webDAV rather than the SharePoint web interface. You could map the SharePoint library as a local drive to make it easy.
Note that drive mapping is considered a legacy technology and will no longer be supported by Windows 11 due to the demise of IE11.
with the push to leverage visual studio and dotnet with office based solutions, especially excel, where is the best article or information on how having office sheet with additional binaries and assemblies is sharable.
Do this external code get packaged with the spreadsheet
what if people start emailing the spreadsheet around. Is there any overhead of this additional assemblies. Is there risk of the binaries getting detached from the spreadsheet
It seems like microsoft has been pushing VSTO for over 5 years now but you read lots of mixed reviews and issues. Are we at the point where companies that do large VBA excel solutions can fully migrate over to dotnet without any real worries?
First of all, I want to answer your question on whether or not VSTO is ready for larger implementations. The answer is YES! Especially if the alternative is VBA. You have the entire .Net framework available, you can use web services, ADO.Net (better still, with the enterprise library). You can still write code that looks a lot like VBA, but is much more powerful. You can get more information by reading Walkthrough: Creating Your First Document-Level Customization for Excel. This page will give you an idea of what VSTO features are available to you.
Now, to answer your question on deployment.
It depends on whether you are making an Add-In or a document level customization. If its an Add-In, then you must install it on each client, and any passing around of documents will not effect that (Add-Ins are at the application level, and not at the individual document level).
I assume that you are talking about a document level customization, so I will center my answer around that.
When you create a document level customization, the assemblies are not loaded into the excel file (as they are with VBA). Instead, a document property is added telling the application that this document contains a manifest file (and tells it of the manifest file's location). The manifest file contains links to the assembly that makes up your customization.
As with any .Net application, there are sometimes other (referenced) assemblies that also need to be deployed. Not always are these assemblies in the GAC, so they would have to be located in the same folder as your executing assembly (in this case, your customization assembly). You don't necessarily have to place your assemblies in the same location as your excel file, though.
There are a few ways you can deploy the customization.
You can store all of the assemblies and the excel file in a folder and run the application that way (if the excel file is passed around, the users must pass around the entire folder).
You can run an setup program that installs the assemblies to a specific folder on the users computer, and specifies the manifest at that location (if the excel file is passed around, the users must also pass around the setup program).
You can install the assemblies in a network location and specify in the document properties, that the manifest and the assemblies are all at that network location (if the excel file is passed around, nothing needs to be passed along with it - but there are security settings that need to be made. Read this page for more information).
Any way that you decide to do this, here is the page you need to read in order to understand the document properties that enable the customization.
You need to make sure all of your users have the prerequisites installed. The easiest way to do this is to give them all a setup program. If you create a setup project for your customization, you can setup the bootstrapper to automatically install the prerequisites. You can also do this if you use ClickOnce to install the customization. This page will give you all the information you need to know regarding deployment.
Here are some other helpful links you will need to see:
Application Manifests for Office Solutions (2007 System)
Deployment Manifests for Office Solutions (2007 System)
Application and Deployment Manifests in Office Solutions
I hope this helps. Once you read all of this information, I think you'll agree that VSTO is a much better choice than VBA. You just have to plan your deployment carefully.
I created a Excel add-on and deployed it to a server. Then I passed around two links, the setup.exe file and the link to the actual Workbook. The workbook file never changed - it's purpose was to open and load the add-on which was now in the user's Add/Remove Programs. The add-on itself would check for updates on startup.
So if they start emailing the workbook around, great! I believe in theory, the workbook would download the add-on if it was missing, but I don't have a fresh computer around to test that. If it doesn't, it's just a simply exe to install (which will update on launch anyhow, so outdated isn't an issue).
For document-level deployment, I recommend the following three links:
https://msdn.microsoft.com/en-us/library/ms268758(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff937654.aspx
How do you assign the Assembly Location of an Excel VSTO Installation?
Unlike application-level solution, document-level has 2 special properties: _AssemblyLocation and_AssemblyName, which indicate the *.vsto position. To set these properties by install path, a custom action project should be created to record the target path when installing, and packaged together with setup.exe. Then you could put your excel file anywhere (on local machine) and open it in the correct way.
One of our product will consist of multiple SharePoint solutions. Now we're wondering what would be the best way to provide an easy deployment to our customers? At the moment we deploy each solution by hand, which is OK during development process but not acceptable for our customers.
For your information, we're using VSeWSS 1.3 for development and solution packaging.
So how do you offer your solutions to your customers? Do you write installation scripts using STSADM commands? What other options do we have?
WSPBuilder
Personally I use WSPBuilder for packaging and find it much easier to work with than VSeWSS. However if VSeWSS is working for you then that's great.
One of many the benefits I found of using WSPBuilder is that it's easy to integrate into a build system. It's just a simple, but clever, commandline tool.
Batch File
For deploying multiple SharePoint solutions to our customers I usually provide a batch file that contains the necessary STSADM command and prompts them to enter any environment specific data i.e. site collection urls etc...
SharePoint Solution Installer
There is also a nice GUI installer,called SharePoint Solution Installer, that you can use in-conjunction with SharePoint solution files. Check it out it might suit your needs.
alt text http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=sharepointinstaller&DownloadId=18625
SAF - SharePoint Action Framework
It's worth pointing out SAF; which is an extremely comprehensive framework that can automate installation and configuration tasks, using either MSBuild, Powershell, Stsadm or a custom SharePoint feature.
We just use plain old batch/cmd files. If you need to "productize" this, just wrap up all solutions in a selfextracting rar package and have it run the batch file after unpacking.
Stick to Microsoft products. Powerbuilder is being groomed to gradually take over from STSADM for this type of task. In a farm scenario (remember, yours may have to grow over time), this would be the tool to use to push out solutions to all front-end Web servers.
EDIT:
MS are preparing a final version of VSE 1.3 to ease the migration of 2007 solutions to the 2010 environment.
Have you looked at Microsoft SharePoint Designer?
not sure if it will do all you need, but it does allow you to package sites or individual objects that you can then run on another SharePoint install.
I want to use the Microsoft.Office.Interop to read an Excel file from a web page.
Do I need to have Office installed on my web server?
I am not doing any manipulation to the excel file, just reading it in and storing the values to another page. I have no issues when I run on my local machine but I have Excel installed on my local machine. Anyone that knows this answer I would greatly appreciate your input.
Thanks
JD
Using Interop requires that you have Office installed on the server. For websites, I would generally recommend using something like the open-source NPOI project. However, if all you ever want to do is read, consider using ADO.NET (see this question for more info).
I would add that if your using Excel as a datasource the ADO approach is much faster and requires less overhead. It restricts you to excel sheets that are pretty much structured as flat tables. But if I can use that method (all restrictions considered) I prefer it.
Ernie
Report design, generation and maintenance isn't hard, but it is dull. We have a number of legacy (to quite different degrees of legacy) reports in Crystal Reports XI. These are designed for A4/PDF - not necessarily printed, but to be of a predictable layout and there's no possibility of us retiring them any time soon.
All connect to existing stored procedures (SQL Server 2005) to acquire their data. A lot of time has been sunk in getting these reports to look just so. The actual creation of reports is mostly done via the .NET/C# API and exported to PDF. There are a number of locally developed and maintained applications that are stable and handle this process well.
So we like the fact that Crystal Reports is stable, that our apps produce these reports reliably, that the PDF output is consistent and that when the Crystal Reports template is approved and set, it just works.
There are some big problems with this situation though. The biggest being that any changes to the underlying report templates themselves are a huge pain; getting the Crystal Reports template to a point that users are happy is a royal hassle and can involve a long iteration of DTP/graphics/database/reconciliation and myriad other niggles.
Combine that with Crystal Reports being a relatively rare skill and not one people want to admit to, we are trying to think up alternative solutions.
Some thoughts I've started to consider - and any others welcome!
Does Crystal Reports 2008 offer any benefits over XI?
How have others managed a migration away from CR? And what to?
Given the data access layer is well formed, perhaps generate graphs via an Excel service and then import them as graphics to a framework template? Crystal, another - has anyone tried anything like this?
Is Reporting Services any better? (We have some RS skillz but again, another thing that people are loath to actually own up to knowing anything about.)
Are there any layout tools available (preferably with a .NET API) for what, in the old days, would be called Desktop Publishing? If we have graphics/tables/other objects as images that could then be rendering automatically,
Ideally I want to move to a solution where the users are in greater control of the underlying changes, and whether this can be handled programatically within tools that we can provide to them and so that I can be coding rather than editing Crystal Reports templates.
So what other problems are you having with Crystal? Sounds like you want the users to handle the reporting...(don't we all). The problem with that is they never want to use whatever data model is offered. Someone has to know how to query the database. You already have that by using stored procedures. Maybe let a couple users learn basic crystal principals (grouping, sorting, summing, etc) and you write the stored procedure and they format it with crystal. That way you bypass the biggest stumbling block with crystal, which is doing the table joins in crystal.
I have crystal knowledge and think it's fairly easy to use. I wouldn't call it skillz though, more like I know what it can and can't do, so I can save myself a lot of time.
I'm not trying to defend Crystal, but if it ain't broke...
We recently upgraded to VS 2008 on XP. Our users are still running the .NET 2.0 framework on Win2K, and a company-wide upgrade is not in our near future. What we didn't find out until we'd already upgraded from 2005 to 2008 is that the Crystal Reports redistributables that come with VS 2008 only work on XP or higher. Oops. So, we're now unable to edit our old reports because CR will automatically update it to the new version.
What I wound up doing is using our existing XMLSerializer, building a class that holds the report data (lots of string and List<T> properties, essentially), and serializing it to an XML file. Insert an XSL stylesheet declaration that transforms it to HTML/CSS, and open it in IE.
It's wound up being quite a bit faster than Crystal Reports, particularly for development, and I can typically have them just give me a Word document of whatever the hell they want the report to look like, export it as HTML, clean it up, and then use that as a template for what the XSL generates.
It's nowhere near as full-featured as Crystal Reports, but for what we need (XRay and Lab reports and work orders), it's perfect.