Our application commonly used an ActiveX control to download and install our client on IE (XP and prior), however as our user base has drifted towards more Vista boxes with "Protected Mode" on, we are required to investigate.
So going forward, is it worth the headache of trying to use the protected mode API? Is this going to result in a deluge of dialog boxes and admin rights to do the things our app needs to do (write to some local file places, access some other applications, etc)?
I'm half bent on just adding a non-browser based installer app that will do the dirty work of downloading and installing the client, if need be... this would only need to be installed once and in large corporate structures it could be pushed out by IT.
Are there some other ideas I'm missing?
This client, is it a desktop application and not some software that runs inside the browser? In that case, please just supply a regular download installer application. My personal experience with browser-hosted installers is that they are just confusing and the few I have seen seemed to be poorly coded in some way.
If you use an MSI based installer I'm sure lots of Windows domain administrators will love you too, as Microsoft has tools to deploy MSI based installations onto large sets of machines remotely.
Its far better to do this right than put it off any longer. Vista is Microsoft's way of saying they aren't letting people get away with ignoring security issues any more and encouraging people to update their code.
I'm sure other users here will be able to point you are some MSDN best practices about writing ActiveX controls.
Have you checked out Microsoft's ClickOnce Deployment?
If I remember correctly you can embed a manifests which would help with dealing with protected modes automatically, saving you those headaches with the APIs.
I believe ClickOnce is geared for the same thing your ActiveX installer was designed to do.
Since you say your IT dept could push this out, I assume you could use this kind of technology as well.
Even though you might not be writing applications on the .NET CLR, you can use Visual Studio to generate those manifest and installers for you.
Related
My goal is to use adminLTE (adminLTE) interface in a corporate setting which allows for VBA scripts to run to automate task which my non-tech savy team can accomplish much quicker than by doing them by hand. (pre-filling emails, providing inventory information, creating and printing forms automatically, integrating with stamps.com, reference and display a lot of excel data). From my understanding, the execution of VBA scripts in a web browser is not allowed.
What are my options for accomplishing my goal?
Do this in an HTA file?
Am I wrong about web browser executions of VB scripts?
Do I need to build an application in Visual Studio?
I have a team of three which need to access this and share data, so it's not like an entire enterprise spread across the nation or anything like that. Thanks.
Any and all thoughts are welcome.
This question is pretty broad - it's the same as asing "what are my options for executing an arbitrary EXE on an end user's computer from a browser." The whole point of browser based applications is to prevent this from happening for security reasons.
If your goal is to deploy VBA scripts to everyone in your organization - that's actually pretty easy - just create an automatically updating Excel addin. This approach is very common and easy to do (more info if needed).
To answer your questions:
Too broad
Yes you can do this in a HTA file but I don't recommend it and I don't think it does what you want.
You cannot run VBA within a browser in the traditional sense. An HTA from what I understand is essentially a desktop app that is written using HTML i.e. you couldn't deploy an HTA to example.com.
You can build a ASP.NET web app in Visual Studio and have your front end (e.g. Admin LTE) call an end point on the backend which then calls an EXE but that would be an EXE on the server and not the client.
When I create an Azure ASP.NET application, by default .NET trust level is Full trust. I always change it to Windows Azure partial trust which is similar to ASP.NET's medium trust level.
You can do it either by using GUI when you select Properties on the Role or by setting enableNativeCodeExecution to false in the definition file (.csdef) just like below:
<WebRole name="ServiceRuntimeWebsite" enableNativeCodeExecution="false">
As a security conscious developer I want by default to run my application in partial trust mode that provides a higher level of security. If I need to use something like Reflection or P/Invoke, as a developer I want to make the decision to lower that trust level by myself.
I'm sure there's a reason why Microsoft decided to use Full trust as a default .NET trust level, I just fail to see it. If you know the reason, or you think you know it, please let me know.
Full trust is not only required for P/Invoke for .NET reflection as well. As a bottom line result, nearly all moderately sized apps need full trust because nearly all widespread libraries need it too (NHibernate for example). Actually, I have been asking from the exact opposite question on the Azure forums too.
The issue of full or partial trust pertains to the environment in which your application runs. The more control and/or "ownership" of the environment and assemblies you have, the more acceptable it is to have full-trust settings.
For example, if you create an Azure web site (July 2012 capability) and, mimicking wordpress or Umbraco, your web site allows arbitrary assembly plugins to be downloaded and installed, then it is important to have a partially-trusted environment. It is possible that one of the plugins downloaded and executed, which you don't control or own, contains malware. Not only does this impact the security and stability of your web site, but some may argue it impacts other (multi-tenant) hosted web-sites which have no relation to yours.
Certainly your web site will rely on 3rd party libraries, such as Log4Net or StructureMap, but those are extremely well-known and vetted libraries that are not in question regarding their security impact. Ergo, if you are running an Azure web-role (a much less "multi-tenant" type affair) and you are merely running such "trusted" 3rd party apps, then there really is not an issue with running as full-trust.
Yes, unfortunately it is still very hard (if not impossible) to write large .NET apps that run in partial trust.
We need much better technology and tools (like CAS.NET)
Because Medium Trust is now officially obsolete. If you start a new web project in Visual Studio, it already requires Full Trust (and doesn't work partial trust). Microsoft says: Do not depend on Medium Trust, instead, use Full Trust, and isolate untrusted applications in separate application pools.
Sources:
Stackoverflow answer: Quoted response ASP.NET team
Microsoft: ASP.NET Partial Trust does not guarantee application isolation
Microsoft: ASP.NET web development best practices
I am currently working on a call log project. The boss wants me to use Sharepoint as a base, so I set up a virtual machine with an instance of MOSS 2007. I downloaded microsoft's call center template and installed it. I have been playing around with it for a little while now and it seems pretty simplistic. How can I modify this template (or extend it?) to suit my needs? I would also like to know how it works so if the need arises I could create my own application, so any help will be greatly appreciated here.
Thanks!
edit:
I am going to go out on a limb here and say that the aspx files I have found inside this folder:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\
have their code-behind already compiled so there will not be much I can do in terms of seeing how the application functions this way. Am I correct here?
I developed several sharepoint features and webparts. And yes, it's a real pain in the a**.
On your Sharepoint Server look at the Directory
C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033
There should be the masterpages and CSS Stylessheet you're looking to modify.
SharePoint development can have a steep learning curve and the product seem to fight against you. This is particularly if you're used to ASP.NET and are used to all the freedom that gives. It's quite a large and sometimes complex product with its own framework and way of doing things. That why I strongly recommend doing some serious reading in conjunction with going in and trying things out with existing applications. A few points:
Support
The primary reason is because you could easily end up with an unsupported installation if you change the file system without realising the impact. This will cause serious problems if it is necessary to install service packs or upgrade to a future version. There is usually a way to deploy updated code to SharePoint without needing to go down this path.
Getting results
Another reason is that unless you know what you are doing, hacking around with little knowledge will usually result in a lot of head bashing and few results. Errors can occur that make little sense or changes that you make won't take affect.
The SharePoint way
Finally, you will seriously waste time trying to get things to work if you don't know the 'SharePoint way' of doing something. Knowing 'the way' can save you so much time and integrate with the product nicely, but if you don't know about it prepare for pain! This includes topics from custom code through to CSS and master pages, through to deployment.
I hope this hasn't put you off as it is possible to enjoy the challenge the product provides and there is some very cool stuff you can do with it. For more reading there are several questions on Stack Overflow about getting started with SharePoint development (this is just one).
My experience with MOSS development has not been pretty. IMO, it is not built for application development or custom code. There are many other portals that fit that need well. For the built in collaboration tools, it is a great tool. Going beyond that, it fights you the whole way.
At least that has been my experience.
What Alex said!
Building a call centre application should be very possible with SharePoint. Personally I'm not a fan of the Microsoft templates but they may help giving you ideas on how to build something like that.
I don't know what your app is supposed to do exactly but by building a few web parts and leveraging the oob lists and workflow features you (or a somewhat experienced SharePoint developer) should be able to create something quickly.
You should not let people with negative experiences throw you off. Like it or not, SharePoint is going to stay and once you get over the learning curve it can be very effective as an application platform.
I can see how installing SharePoint can be a pain if you've got no clue what you are doing but it's a server application; a little learning should be expected.
I've got a strong background in Linux and OSX, and just left a job where I was architecting systems based on those platforms.
Now I've got a Windows Server running IIS that has a number of different websites that it hosts. Most of them are just a bunch of HTML, JS and Images, with some ASP for some customer tools. (Each website has a different set of customer tools, or they are the same tools, but with minor code changes between them.) I'm also adding a develop web server with the same code, but the 'bleeding edge' stuff.
I need an effective way of managing changes and updates to the overall codebase (henceforth referring to both the images and the html and the asp, for all the sites). When a dev (or webmaster) checks in changes, I want it to show up automatically on the developer server, but should be manually pushed out to the live server. I'd be tempted to just make the websites SVN repositories, but I'd be concerned about the overhead of having the webdeveloper having to log into the server and trigger an SVN update via commandline/tortise (and heaven forbid, manage tags).
Ideally I'd also manage IIS profile settings between the systems, but the major need is to be able to manage the process, and expose it to our ASP developer, and our webmaster, both of which are used to just FTPing up the files to the live site.
So, any recommendations on tools (beyond some SVN hacking with BAT files + teaching the webmaster how to log into the server and do updates) or workflows that would help this out? I even considered an RPM type package (or some Windows equivalent, of course) to manage the live server, but that seems like a bit too much overhead.
First you need to decide how the webmaster knows that the latest in your SCM is ready for deployment (I assume you want some level of acceptance testing after the developer has checked in).
Depending on the above answer you should be able to define the steps to get the "approved" content built and updated on the web server, then it would be a matter of scripting this.
In the end the problem is not the commands to run, but knowing /when/ to run them, and that the last checkin from developers is not necessarily going to work 100% (even without mistakes two concurrent changes, each working, could conflict).
I work for a very small company (~5 employees, 2.5 coders). We have gotten away with no code or document management for several years, but it's starting to catch up with us as we grow a bit.
Any suggestions for a management system. Free is better, but cheap is acceptable. We just don't want to spend more time on installation/configuration than it is going to save us.
We use mostly VC++ 6, but we're branching into VC# 2008. Also, we need to keep track of mechanical drawings and circuit diagrams for several pieces of hardware, as well as user manuals for both hardware and software (but I don't really expect to find one tool that will do all of this, just hoping).
Subversion (SVN) is an excellent option for you. It's free, integrates nicely into Windows with TortoiseSVN, and is well-tolerated by users.
We are using it for source code, as well as for document management.
http://trac.edgewall.org/ - might be a bit hard to install but otherwise is very good if coupled with svn repository
Mantis is good for issue tracking. Subversion for source control. Both are free.
For documents, I do not know. Sounds like you would do fine with a network share.
You may want to look at Trac.
I work for a similar sized company, and when I got here I was in the same place as you. I implemented SVN/Subversion http://subversion.tigris.org/ quite easily. If you use the svn protocol and use svnserve (can be setup as a windows service that auto starts on your server) it should take you 1.5-3 hours to setup depending on how much you want to read http://svnbook.red-bean.com/, see collabnet http://www.collab.net/downloads/subversion/ for the Windows package download
Using Windows, you can use Tortoise SVN which integrates into the windows shell. There is also a new release of Ankh SVN (2.0) http://ankhsvn.open.collab.net/ that integrates into Visual Studio. Ankh is very nice (has pending changes window, kind of similar to Subclipse like functionality) but it is a new release and is somewhat buggy (we have experienced some memory probs and slowness). We currently use both Tortoise for initial checkouts or imports and Ankh for everything else and are pretty happy.
If you have any Mac users, there are a lot of options out there. We have a mac user here who uses Versions http://www.versionsapp.com/, though it sounds like they will charge for it once they get out of beta.
I would recommend SVN because it is widely used out there and I feel that is important with open source projects you are going to use daily for production purposes. Just to spell it out, everything (other than Versions) mentioned is free.
Perforce!
It's extremely fast compared to most other source control systems. It works great remotely. (SSH tunnels, in my case)
The VS plugins are quite decent... I haven't tried the Eclipse one that much yet.
If you can get by with two users with 5 workspaces each, then you can use it for free. (I do, currently)
If that won't work, then it does cost a bit... something like $800/user I believe. Sometime next year I'm probably paying that. (5 workspaces is tough when you work on several machines with VMs)
Still, I heard the slower-than-glacial ClearCase/ClearQuest system one client one mine is using was something like $10k per developer, so expensive where source control is concerned is a relative concept.
Don't skimp on the source control, man! Slow source control is a serious pain in the a$$.
Avoid SourceSafe-like systems that only version files... use systems that track tasks or change sets. It's very useful to see what all belongs together as a task. Tags are not an acceptable substitute.
Also, the journalling nature of Perforce makes backups and recovery a lot easier.
Use Git for source control, Basecamp/Pivotal Tracker/Unfuddled for coding workflow, and Sharepoint/Google Docs for document management.
If you get a MSDN developer license, you can run TFS workgroup edition. That has source control and document management rolled all up in one package that's pretty easy to use and manage. That, in addition to an internal wiki, is what my company does.
Use Subversion. It's free and is the preferred source control system for the vast majority of open source projects.
SVN uses shallow copies, so when you have large files in a repository and you branch, a full file copy isn't done... just a pointer to the original. As for text files (code) only diffs are stored.
Use TortoiseSVN for windows explorer integration.
TFS is a pig, and you'd need to open visual studio to interact with source explorer. Stupid for a CAD engineer to have to need a license to TFS for that.
For document management, just use Windows Sharepoint Services that comes with Windows Server 2003 (or 2008).
I also work for a small company and we mainly develop in .NET languages. We have decided to use Visual SourceSafe for source control, despite its questionable reputation, since it integrates nicely with Visual Studio. VSS works very well for us, and we have not experienced any serious problems with it. Also, we host a SharePoint server, which we use to store documents like coding standards, storyboards, and even our SCRUM log.
We use HostingPlayground. For $6 per month we get multiple Subversion repositories and an instance of Trac. Can't beat it. And since its a service its available immediately.
It seems the solution for your 'management' requirements will require at least a tool or set of tools in the following categories: (sorry about the links, not enough reputation to put proper ones in the reply)
Source Code Management
Trouble/Bug Ticketing
Document Management
Definitely take a look at stackoverflow.com/questions/15024/tools-to-help-a-small-shop-score-higher-on-the-joel-test Tools to help a small shop score higher on the joel test referenced by stackoverflow.com/questions/84303/code-document-management-for-a-very-small-company/84363#84363 Kristopher
Each have various free/open source solutions, and likewise there are commercial solutions.
Source Code Management (SCM)
A significant trend(?) of source code management is evolving from centralised code management with something like TFS(?), cvs or subversion.tigris.org svn), to decentralised 'distributed' source code management with tools such as www.selenic.com/mercurial/wiki/ or git-scm.com/. Some of the tools either integrate into continutation
The above mentioned source code management tools all have nice ms windows integration tools, and some even have closer Visual Studio integration (e.g. TFS, ankhsvn.open.collab.net/ ANKH svn mentioned by Mario).
A simplistic generalistion would recommend git/mercurial when your coding involves a good portion of time away/off disconnected from your centralised source code repository (such as doing a lot of coding from home when your repository is not accessible through the Internet.)
Wikipedia has a en.wikipedia.org/wiki/Source_code_management nice overview of the various issues related to source code management, and the benefits of various options.
If you haven't used scm before, just pick one or two of the tools that fits your groups requirements and test it. Of course, if you know someone near who has experience with a particular scm solution it may help with the team's learning curve to have that shared experience around.
My pick for your scenario: Subversion with ankhsvn.open.collab.net Ankh SVN for Visual Studio integration.
Trouble/Bug Ticketing
None of the tools available solve everything for everybody, each have their advantages and most require some compromise from a development teams existing modus operandi. Again, wikipedia is your friend with a en.wikipedia.org/wiki/Bug_tracker general summary and en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems comparison of major tools.
Installation
The php based tools are the easiest (in my experience) to get up and running, and the perl tools more involved(?) Of course there's python one that's real easy to install, but then requires a better mind than mine to configure.
My pick for your scenario: trac.edgewall.org/ Trac
Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team's established development process and policies.
It provides an interface to Subversion (or other version control systems), an integrated Wiki and convenient reporting facilities.
Trac allows wiki markup in issue descriptions and commit messages, creating links and seamless references between bugs, tasks, changesets, files and wiki pages. A timeline shows all current and past project events in order, making the acquisition of an overview of the project and tracking progress very easy. The roadmap shows the road ahead, listing the upcoming milestones.
Drawings/Document Management
If you use Subversion with Trac then much of your document management may be solved with these tools. Otherwise another stackoverflow discussion topic: stackoverflow.com/questions/587481/developer-documentation-sharepoint-document-management-vs-screwturn-wiki Developer documentation sharepoint document management vs. screwturn wiki, for Windows centric environment, is a good read.