We use SpreadsheetGear with c# scripts.
Currently it's installed on Windows 2008 R2. We need to move it to another server running Windows 2016. How do I go about the installation so that our scripts keep running without interruption.
Thank you.
You should not need to install SpreadsheetGear on a server. SpreadsheetGear is a component / library for .NET developers, so you would typically be adding a reference to one or more SpreadsheetGear assemblies in your own Visual Studio Projects, then build and deploy your own entire application to whatever location you need, such as a new server.
If you are using the SpreadsheetGear for .NET Framework product, it is distributed as installers from the SpreadsheetGear website (see the Licensed User Downloads page), but these installers are intended to be run on a developer's machine (it provides samples, documentation, integration with Visual Studio). You should not be installing these directly on a server.
If you are using the SpreadsheetGear for .NET Standard product, then this is distributed as the SpreadsheetGear package on NuGet, and you'd simply add a reference to it within whatever Visual Studio Projects require it.
Related
I'm not asking a technical question, but a request for advice.
Over time, I have always used installshield as the primary tool in installer development, and this tool has always been the king of them.
Lately, everything has gone to the web and Windows Forms have lost their charm. However, these still exist, and there are needs about them.
But you don't see anyone talking about the latest technologies about Windows Forms, installers...
Do you think Installshield is still the main tool for build installers? Why isn't any extension available in the VSTS/TFS vNext market?
Even in Jenkins, the last time the plugin was updated ... was in 2014. And we remember that Microsoft used Installshield Limited edition for one Visual Studio Version, but dropped to bring back Visual Studio Installer.
Tools such as Bower, Grunt and Yeoman have surged in popularity recently.
Whenever I've read about them or come across them in an article, I've dismissed them as tools used for Mac-based front-end devs or PC-based but not on the Microsoft stack - Sublime Text etc.
Visual Studio has NuGet, project templates, MSBuild, MSDeploy, TeamCity/TFS Azure etc. and I generally consider VS has being a very highly automated ecosystem (some say it makes us productive at a cost of understanding).
How are these tools being used by ASP.NET devs on VS?
Note: This is not an opinion-based question, I'm looking for real-world examples of how these tools are being used.
There is a Package Intellisense extension for Visual Studio which adds bower and npm package support
Grunt/Gulp launcher extension for launching grunt/gulp tasks
Read this awesome article written by Scott Hanselman for more info:
http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx
UPDATE:
These features are now fully integrated into Visual Studio 2015:
http://www.asp.net/vnext/overview/aspnet-vnext/grunt-and-bower-in-visual-studio-2015
Great tips from john papa:
http://www.johnpapa.net/get-up-and-running-with-node-and-visual-studio/
As per Scott Hanselman's blog posting, he says this about the reason why a VS dev might want support for these tools:
Some of you may ask, why not use NuGet for JavaScript? Why not extend
MSBuild for building CSS/JS? Simple. Because there's already a rich
ecosystem for this kind of thing. NuGet is great for server side
libraries (and some client-side) but there are so many more CSS and JS
libs on npm and bower. MSBuild is great for server-side builds but can
be overkill when building a client-side app.
So, use both. These are tools in your toolkit. Adding support for
Gulp, Grunt, Bower, npm (and other stuff, in the future if needed)
means a more familiar environment for front-end devs doing ASP.NET and
it opens the doors for ASP.NET devs to bring in the JS and CSS
libraries communities use every day.
Though I'd still be interested in other people's take on how these tools fit in to the 'workflow' of a VS developer. For example, "Before I installed Grunt, I wasn't able to easily... blah."
Update
I'll stick some updates in here as I learn things.
So, new learning no.1: Yeoman scaffolds front-end, client-side code. Whereas VS scaffolds server-side stuff and project templates (that don't change for months/years), Yeoman can help with boilerplate for fast-changing JS MV* frameworks, for example.
New learning no.2: the tooling is not ready for prime-time enterprise dev.
The first problem is that npm downloads dependent packages into nested subfolders and recurses this model exhaustively, so you end up with folder paths that are 100s of characters long. Windows and some tooling goes nuts. There are workarounds but its a serious flaw.
Latest Node and some added command line options now make this better behaved.
Developers running Windows are often in enterprise settings which means proxy filters and auth. For me, I needed to install Cntlm local proxy to get NPM and other tools to work via our proxy, which violates our IT policy, I just didn't tell them.
Some of NPMs packages seem to want to clone Git repos using SSH! Port 22 is not open; because the community is so Linux/Mac non-enterprise oriented, such issues arise because they're not a problem for so many creative-agency devs and then can hang around for months.
New learning no.3: how dynamically downloaded JS files end up as content in the project file and thus added to an MS Deploy package is still an unknown.
Update on learning 3, we created a build that just transformed the config files, then we used the MSDeploy command line to copy files individually to the destination server. Not something I'd do if I were working alone, it took weeks on and off, to automate all this.
With Bower updates are faster. Every time a new version or update is released we can easily find it in Bower. You no longer have to wait as we had to with NuGet.
So we could say that NuGet continues to be the king in the server side, but Bower is the new king of client-land.
Take a look in this post for more details and see a simple example:
http://nearsoft.com/blog/bower-and-asp-net-5-a-tutorial/
To answer the original question with a perspective from both enterprise and casual development...
History
Visual Studio has always been a standard development tool for efficiently building large-scale enterprise applications for Desktop, Mobile and Web. This included both client-side and server-side web applications built using Forms, MVC and the .NET Framework. Of course, what makes Visual Studio so appealing is the power behind it, which gives developers the ability to quickly generate, or scaffold, common solutions via project templates - allowing developers to focus on solving business problems.
For simple client-side web sites that use a few libraries and require minimal data interaction, a tool such as WebMatrix would often suffice due to being lightweight and able to serve up web sites with ease.
Many of those tools and technologies can be found at Microsoft /web.
Divergence
At the same time, there has existed a burgeoning Open Source community that has been developing many of the libraries and frameworks that have risen in popularity for building modern web sites and web applications.
For developers working with the "Microsoft Stack" of technologies, the gap was originally bridged by integrating NuGet into Visual Studio. Many, but not all, libraries and frameworks were available as NuGet packages; and there was plenty of support from Microsoft for working with these technologies. Microsoft had also created it's own open source mini-ecosystem called CodePlex to support development and sharing of projects, usually focused on their technology in some way.
Unfortunately, while the availability of technologies was fairly up to date for Microsoft developers, it had become more and more challenging to keep up because it wasn't just about the libraries and frameworks, but the workflow and the way these technologies were being made available, integrated and used.
Such workflows include:
client-side package management via Bower from Twitter
(Bootstrap, etc.)
node-based package management via NPM
client-side application scaffolding via Yeoman (e.g. generators for ASP.NET and knockout)
automated task running via Gulp and Grunt
pre-compiling CSS from either SASS or LESS
transpiling languages such as ES6 or TypeScript
testing (Jasmine, Karma, etc.)
bundling and deployment (Webpack, etc.)
Unfortunately, much of this is a manual process, such as identifying the right package for the job or writing different tasks that can eventually be run automatically. Each is truly a subject in and of itself! It's not uncommon to end up simply looking up a package or command for something that in the end could - and Visual Studio developers would say should - be automated.
Convergence
Microsoft has been slowly moving from not only supporting open source development but embracing it. It has made many of its core technologies available to the open source community via GitHub, as well as it's own .NET Foundation movement.
A major effort to converge by Microsoft was to introduce Visual Studio Code for multiple platforms - offering a simplified development experience that caters to the workflow that has become popular with the open source community.
Still, Visual Studio Code can be viewed as a major step back for developers used to much of the power and simplicity offered through Visual Studio through its automation of tasks and project templates. Microsoft introduced Web Essentials for 2010 and 2013 editions to keep up; but as many have observed, this was simply more of an effort to show support rather than a full integration into developer workflow.
Behind the scenes, Microsoft was looking to put it's .NET Framework on other platforms and established .NET Core. As of Visual Studio 2015 - specifically Update 3 and Node Tools - there is much deeper support for the open source development workflow with integration of NPM and Bower, as well as task running. These still require manual intervention but it's on par with the workflow outside of Visual Studio. It still feels foreign, but it's getting there.
The Future
With all that Microsoft has invested, it is clear that the next step is to bring together much of the steps taken to embrace open source development by providing a more visual and automated experience to Visual Studio Developers. This will include templates that generate rich web applications which not only have all of the necessary packages and dependencies defined, but the ability to bundle for distribution.
In the meantime, I think this is a great time for Visual Studio developers to get a feel for the current workflow, if just to appreciate how "the other guys" have been doing it. It won't be long before much of it will be simply a click away.
We recently upgraded a major application to Visual Studio 2010.
Unfortunately, we are still using several database servers that are still running SQL Server 2000 (8.0.2055 to be precise).
According to this article (Link), "Since mainstream support for SQL Server 2000 ended on 04/08/2008, Visual Studio 2010 will only support debugging SQL Server 2005 and SQL Server 2008.
We have a lot of stored procedures that we keep in Source Control and execute them from within Visual Studio whenever we need to update them.
Is there any way around this restriction? 3rd-party tool, anything.
While researching this, I saw a few sites that indicate an ODBC connection could be used to get to the SQL2000 box. I was able to create a System DSN and then a Data Connection within VS2010, but am unable to connect to it.
Any help would be greatly appreciated.
Thanks.
Chris
The only way I've found so far is to extract our data library out of the project and keep it in VS 2008 targeted at 3.5 while we're building it. Once it's complete and ready, we open up the primary project in VS 2010, check out the changed files and then use the file system to copy the changed files over.
We then keep the supplementary 3.5 project in source control parallel to the primary project.
They will still build and function in .Net 4.0, but we have found that the IDE will not accept any connections or commands to them.
I am not able to create new web application through Visual studio 2003. when i am trying to create web application i am getting an error like "Cannot find the components for communicating with the FrontPage server extensions". Bu at the same time i can create windows application.
Please help me on this...
I would check you definately have Front-Page extensions installed on your web server. In the control panel go to Add/Remove Programs and switch to the Add/Remove Windows Components. Double click Internet Information Services (IIS) and you will see Front Page Server Extensions listed. It should be checked, if not then check it and accept changes, you will need your install media to complete the update unless they were copied to your hard drive.
You could try reinstalling Visual Studio 2003. It sounds like some DLLs might have disappeared.
I have uninstalled both IIS and VS2003 and then installed IIS followed by VS 2003...
now it is working fine..
Problem was because of i installed VS2003 first and then IIS...
so make sure we have to insatll IIS first..
Thanks
What is "missing" in the Visual Studio 2008 Express Editions?
In particular,
what functionality is not available?
what restrictions are there on its use?
The major areas where Visual Studio Express lacks features compared to Visual Studio Professional:
No add-ins/macros
Some Win32 tools missing
No Team Explorer support
Limited refactoring support
Debugging is much more limited (particularly problematic for server development is no remote debugging)
Lack of support for setup projects
No report creation tools
No Office development support
No mobile platform support
Limited set of designers
Limited set of database tools
No code profiling or test framework support
No MFC/ATL support
No support for compiling C++ to 64-bit images (workaround is to install Windows SDK which is free)
NOTE: it is often said that the Express EULA does not permit commercial development - that is not true (Visual Studio Express FAQ Item 7)
There's a handy set of comparison charts on microsoft.com.
It depends on the particular express edition, of course (since there are several and they have different features). The limitations you're most likely to run into are source control integration (and TFS client license), debugging limitations, limited refactorings, no unit testing support, and limited designer support.
For completeness sake, here's a list of features that are in Visual Studio 2008 Standard Edition but are in none of the express editions:
Add-Ins
Macros and Macros IDE
Visual Studio Add-in project template
VSPackages
Wizards
ATL/MFC Trace Tool
Create GUID
Dotfuscator Community Edition
Error Lookup
Source Control Integration
Spy++
Team Explorer Integration
Team Foundation Server Client Access License
Visual Studio 2008 Image Library
Add-Ins/Macro Security options
Visual Studio Settings
Class Designer
Encapsulate Field Refactoring
Extract Interface Refactoring
Promote Local Variable to Parameter Refactoring
Remove Parameters Refactoring
Reorder Parameters Refactoring
Debugging Dumps
JIT Debugging
Mini-dumps
Multithreaded/Multiprocess Debugging
NTSD Command Support
Step-Into Web Services Debugging
CAB Project Project Template
Merge Module Project Template
Publish Web Site Utility
Setup Project Template
Setup Wizard Project Template
Smart Device CAB Project Template
Web Setup Project Template
Windows Installer Deployment
64-bit Visual C++ Tools
Create XSD Schema from an XML Document
Reports Application Project Template
Visual Studio Report Designer
Visual Studio Report Wizard
Shared Add-in Project Template
ASP.NET AJAX Server Control Extender Project Template
ASP.NET AJAX Server Control Project Template
ASP.NET Reports Web Site project template
ASP.NET Server Control Project Template
ASP.NET Web Application Project Template
Generate Local Resources
WCF Service Host
WCF Service Library Project Template
WF Activity Designer
Custom Wizard Project Template
WF Empty Workflow Project Template
MFC ActiveX Control Project Template
MFC Application Project Template
MFC DLL Project Template
WF Sequential Workflow Console Application Project Template
WF Sequential Workflow Library Project Template
WF Sequential Workflow Service Library Project Template
WF State Machine Workflow Library Project Template
WF State Machine Workflow Designer
WF State Machine Workflow Service Library Project Template
WCF Syndication Service Library Project Template
Visual Studio Extensions for Windows Workflow Foundation Designer
Windows Forms Control Library Project Template
Windows Service Project Template
WF Workflow Activity Library Project Template
WPF Custom Control Library Project Template
WPF User Control Library Project Template
ASP.NET Server Control Item Template
COM Class Item Template
Configuration File Item Template
Frameset Item Template
Interface Item Template
CLR Installer Class Item Template
Local Database Cache Item Template
Module-Definition File Item Template
Nested Master Page Item Template
ATL Registration Script Item Template
MS Report Item Template
Report Wizard Item Template
.NET Resources File Item Template
Win32 Resource File Item Template
Static Discovery File (Web Services) Item Template
Transactional Component Item Template
Web Content Form Item Template
Windows Script Host Item Template
Windows Services Item Template
XML Schema Item Template
Here's comparison chart of editions
Edit: didn't realize this was for 2005, not 2008
Visual Studio 2008 Product Comparison
As far as I know there are no restrictions on its use, but I'm not a lawyer.
AviewAnew pointed out you can use Express Editions for commercial use: there are no licensing restrictions for applications built using Visual Studio Express Editions. See FAQ #7.
These are the most significant for me:
You cannot set breakpoints with a condition
Add-in support
Refactoring is very limited (rename, extract method)
MFC is the most important missing thing in my opinion.
No add-ins allowed
Other people have posted huge lists, but as a practical matter, speaking as someone who does mostly systems programming, the features I miss most when using the express edition are
the thread-aware parts of the debugger,and
the ability to open files with the built-in binary viewer.
If I did MFC programming more often I would probably miss the dialog designer as well.
One that is missing (which is nice to have) is:
Source Control Integration
enables two
options: source control solution based
on the Source Control Plug-in API
(formerly known as the MSSCCI API), or
a source control VSPackage
This is particularly important especially if you're working with systems like Perforce where you must check out files before changing with them, particularly changing project settings for all team members.
This MSDN document should get you everything you need!
Note that currently, you can't get F# in an Express edition, though I imagine that this is likely to change at some point in time.
There is a workaround - you install the Visual Studio Shell and F# CTP separately and they work together.
I had trouble with Visual Studio Express (C++) 2008 (with service pack 1) on Windows Vista, with debugging. Any time I did anything such as (a) break the program, (b) set focus from the app back to the IDE, (c) resume execution, the program hung for about 30 seconds. Task Manager showed "VSExpress.exe" consuming an entire CPU for the duration. Vista showed "Not responding" in the IDE's title bar during this time.
This was driving me bonkers so I bought a commercial copy of Visual Studio Professional 2008 ($150 from SoftwareSurplus) and this solved the problem.
For Visual Studio 2008, the Express editions do not have the built-in testing features for one.
You can build MFC applications if you download the libraries in the Platform SDK. But there is no built in support for designing dialogs.
Add-ins are allowed in Visual Studio Express. The most notable one is straight from Microsoft: XNA Game Studio works as a Visual Studio Express add-in.
There's even a project type (maybe only available in the full Visual Studio) that lets you build your own Visual Studio Express add-ins!
You can't create Windows services for one.