I am trying to publish a little app which runs fine on the dev machine, but when I install it on a fresh win7 machine with no office installed. When I try parts of the app that rely on access DB I get this error. Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
I have been at this for a couple hours now and not sure what the problem is. I went to Build Configuration Manager and set the Platform to X86 from everything I have been reading everyone says to do this and it should work this hasn't done anything.
I am also using installshield but I don't see any prereqs for access db engine or anything.
Anyone know what I need to do to get this app to work on other windows machines?
I had a similar situation where my app needed a specific db provider. I added it as a prerequisite in InstallShield. Go to Tools / Prerequisite Editor to add a new prereq to your install project. On the Conditions tab, you will most likely want to make sure that a registry key exists for the provider you want.
Then on the Files to Include tab, add a reference to a local file (or url) for the provider you need.
Not a complete answer, but hopefully gets you going in the right direction.
Related
Are there any Azure Automation DSC gurus who can help with some guidance and know-how for pushing through a couple impasses I am currently encountering?
The task at hand is: Use Azure Automation Runbook to provision a VM. That VM should immediately be associated with a DSC configuration, which will adjust Windows features, settings, and install SQL Server according to a specific configuration. All tasks conducted need to be written in PowerShell and should require no manual input via Azure portal at any point.
At this time, the Runbook provisioning the VM is working perfectly. However, associating this new node with a DSC configuration is still a manual process, which also is working (with the exception of the next issue mentioned below). However, this process needs to be automated instead. How is this done? Via DSC resources as children of the VM resource in the ARM template?
Getting SQL Server installed is the next step. The xSQLServer DSC module seemed perfect for achieving this, but it currently has a bug in Azure Automation, which means that the xSQLServerSetup resource is not available, even when using older versions of xSQLServer. So, there appear to be two possible workarounds to this…
Workaround 1: Not use xSQLServer and just run a PS script that is local on the newly provisioned VM to install SQL Server using a command line installation using an INI file. The PS script to install SQL works, but only when run manually. When attempting to have DSC run this script, Azure is throwing an error that the script is not digitally signed. So, there appears to be a permissions scoping issue at play, and the DSC credential is not able to run the local PS script even though the local admin credential is being passed in. How does one get around this?
Workaround 2: Apparently, it is supposed to be possible to provision a VM, compile the DSC MOF local on that machine (with the full version of xSQLServer), and then push that registration back to Azure Automation. Though, it is unclear how exactly this would be done, as it appears to also require the execution of a local PS script, thus providing the same impasse as the first workaround. Is this perhaps via a Custom Script extension in the ARM template, or…?
I can see all of the parts in play, and I’ve found several helpful resources online that give breadcrumbs to the solution. But, the breadcrumbs are too far apart, and the proper way of wiring everything together is proving to be elusive. So, I’m here humbly asking for help and guidance in getting this worked out.
Any help would be greatly appreciated.
Thanks!
First of all that's a lot of questions instead of 1.
unless this is some kind of homework - there is no point in installing sql on a vm, there are a lot of vm + sql images in Azure and it would take 5 minutes instead of 60 to provision such a vm.
When attempting to have DSC run this script, Azure is throwing an error that the script is not digitally signed. - this means your script is not signed (not related to rights\permissions), look for execution policy, you need to set it to unrestricted before running your script (but you don't need to, because of the first point).
you compile mof or upload it and then you can "tie" a vm to that mof, it can be automated with powershell (both parts), there are a lot of guides on how to do that. Like this
As a general rule, use arm template to do the whole thing, again, there are lots of examples on how to achieve that (just browse this repo). Provisioning infrastructure with powershell (on azure) is not the best way of doing things.
Is it possible to customize the DNN 8 modules and Skins? Is it possible to config the DNN 8 and use it in VS 2010 framework 4.0? If is it let me know the steps to do, because I have configured DNN 8 site to the IIS 7 and it works good from the there, but when I am trying to load this to the VS2010 and Build it, it gives me different errors.
Errors:
i) Unknown server tag 'dnn:DnnCssIncludes' - Which was resolved by adding one line for dnn tag in the same file.
ii) After resolving previous error the another error wsa of ckFinder, and it was resolved by adding ckFinder.dll file in bin folder.
iii) After resolving previous issues it generates new error for ckEditor. It shows me the following error message:
The type or namespace name 'Ventrian' could not be found (are you missing a using directive or an assembly reference?)
I have tried to resolve and search for the solution but fail to do. Will any one let me know the fixes for this?
Yes, this is possible, you will want to do a couple of things
Setup your Environment
Open the Project for whatever you are modifying, this typically involves install the SOURCE package of the extension you want to modify.
Don't change "core", meaning don't change "DNN" itself, you can, it's open source, but once you do you are forked and upgrading to new releases of DNN is very difficult to do if you aren't careful.
Setting up your environment
From http://www.christoc.com/Tutorials/All-Tutorials/aid/1
Setting up your development environment can vary based on what your end goal is. If you are doing module development for your own use, and within your own DNN environments, you can ignore a few of the settings below. If you are doing module development with the idea that you might turn around and give the modules away, or sell them, then you will likely want to follow the guidelines set forth below to support the widest array of DNN installation environments.
I recommend that each developer have their own local development environment, with a local IIS website running DotNetNuke, and a SQL Server 2008/2012 (not express, though you can use it) database for the website. Having an individual development environment makes group module development far easier than if you share environments/databases.
Choosing a DotNetNuke Version
Choosing a version of DotNetNuke is important when you start your development for couple of reasons. For modules that you are developing for yourself, you need to ask, what is the minimum version of DotNetNuke that you have in production. Are you running DNN 5.6.1? Are you running 6.2.6, 7.0.0, 7.0.6? Based on the answer you can determine what version of DNN you should setup as your development environment. You shouldn't be developing on a newer version of DNN than what you have running in production. As with everything there are ways around this, but I am not going to go into the details on that in this tutorial.
As a developer working to create modules and release those, you might have production sites that are running on the latest and greatest version of DNN, but what about your customers? Or your potential customers? You have to ask yourself, do you want to provide support for really old versions of DotNetNuke? From a development perspective you will probably say no, but from a business perspective, you might say yes, and here’s why. Not everyone upgrades DotNetNuke websites as they should, and often times you will find that some people never upgrade. While I don’t advise taking that approach to managing a DotNetNuke website, it is a fact of life that people don’t always upgrade and there are thousands of people, if not tens of thousands, that have sites that aren’t running on the latest version of DNN. You should take that into account when you are doing your module development, if you compile your module against an older version of DNN then your module should run on newer versions of as well, for example. If you compile your module against DotNetNuke 6.2.6 it will likely run on every version of DNN released since then. Though there are extended cases where this won’t always work, DNN strives to maintain backwards compatibility, this isn't always possible.
You might also want to use features that are only available starting with a specific version of DotNetNuke, such as the workflow functionality found starting in DNN 5.1, in that case you may choose not to support older versions of the platform out of necessity. This will minimize the market in which you can sell your modules, but also can make for less support and an easier development cycle due to the features that DNN provides.
Choosing a Package
Now here’s one that may baffle you a bit. I’m going to recommend that you use the INSTALL package for whatever version of DotNetNuke that you download. What? The INSTALL package? What about the SOURCE package? Well you can use the source, but you don’t need it. The module development that I’m setting you up for doesn't require the DNN source, and using the INSTALL package makes your development environment cleaner. We aren't going to be opening the DotNetNuke project when we do our module development, so why have the files sitting around for nothing? Also, if you've ever tried to use the SOURCE package for anything, you'll know it isn't easy.
The steps for setting up your development environment will apply to both the Community and Professional editions of DotNetNuke.
Installation Configuration
Once you have the version selection out of the way you can go through the installation process. While I’m not going to walk you through the minutest of details of each step of installing DotNetNuke in this post, I will at least try to point you in the right direction for each step.
Download the INSTALL package of the version of DotNetNuke you want to use in your development environment.
Extract the files in the INSTALL package to a location of your choosing, this location is where you will point IIS (the web server) when we can configure the website. In my environment I typically use c:\websites\dnndev.me\ (One item of note: you may need to right click on the ZIP file and choose Properties before extracting, on the properties window if you have an UNBLOCK option, click that. Some versions of Windows have started blocking files within the DotNetNuke ZIP files, which will cause you problems later during the actual install.)
Setup IIS
IIS is the web server that comes with Windows computers. DNN 7 requires IIS 7 or later (7,7.5,8.0), so you will need at least Windows Vista, Windows 7, Windows 8, or Windows Server 2008 R2, Windows Server 2012.
In IIS you should create a new website (Note: If you use an existing website in IIS be sure to add the HOST binding for DNNDEV.ME), and point to the folder where you extracted the INSTALL package.
Note: With DotNetNuke 7.0+, .NET Framework 4.0 is required, so be sure that your application pool is configured to run under 4.0, and not 2.0.
Set File Permissions
Setting up the file permissions for your DNN install is often the step that causes the most trouble. You should right click on the FOLDER in which you extracted DNN (c:\websites\dnndev.me) and choose properties. Choose the Security tab. You need to add permissions for the account in which your website's application pool is running under. You will want to setup the permissions to give the account Full or Modify permissions for the DNNDEV.ME folder. Which account you will use will vary based on your version of IIS, here’s a simple list of some of the default accounts based on the version of IIS.
IIS Version Operating System Account
IIS 7 Windows Vista, Windows Server 2008 localmachine\Network Service
IIS 7.5 Windows 2008 R2, Windows 7 IIS AppPool\APPPOOLNAME
IIS 8 Windows 2012, Windows 8 IIS AppPool\APPPOOLNAME
Note: If you are using IIS7.5/8.0 you’ll notice in the above table that we have APPPOOLNAME in the identity, this is because when you setup a new website in IIS a new application pool is created. In place of you should type in the name of the application pool that was created. You can also bypass this and configure your application pool to use the Network Service account instead of a dynamic account if you would like.
Database Configuration
In SQL Server you should go through and create a new database. I always create a database with the same name as the website, so in this case DNNDEV.ME. Once you have created the database, create a user that can access that database. I always use SQL authentication, turn off the enforce password requirements, and give the user DB Owner and Public access to the DNNDEV.ME database. Remember the username and password you create here as you will need them when you walk through the Installation screen for DotNetNuke.
DotNetNuke Installation Screen
Populate the installation screen with the standard DNN information, Host username, password, etc. For the Database option, choose Custom and configure your database connection, providing the Server IP/Name, the Database name (dnndev.me). For the database authentication you'll want to choose the option that allows you to enter the username/password for the database user that you created previously.
Now there are two additional options you can configure, normally I would tell you not to modify these, but from a development environment perspective I do recommend that you change the objectQualifier setting. It should be blank by default, you should type in “dnn” (without quotes), this will prepend “dnn_” to all of the objects that get created by DNN such as Tables and Stored Procedures. This is not something I recommend from a production stand point, but if you are developing modules for sale, then supporting objectQualifier in your development is recommended. It will save you time down the road if you have a customer who has an objectQualifier defined on their production databases.
DotNetNuke Module Development
To get started with your DNN module development, be sure to read our tutorial on how to install our Module Development Templates.
Next, setup Visual Studio Templates (you'll want to use VS 2015) and create a project.
You can find the templates here https://visualstudiogallery.msdn.microsoft.com/bdd506ef-d5c3-4274-bf1d-9e673fb23484
Download that, run the VSIX package installer, or search through the online templates for DotNetNuke. Watch this video https://www.youtube.com/watch?v=kOoQJDeTlJ0&list=PLFpEtny5sIbb9jGxJ7RBM5hIizodOCtoj&index=1
I have an issue installing two ClickOnce Windows applications on the same server. I have published one successfully. I have a requirement to install this same application on a different website in IIS. This is a copy of the existing application with slightly different functionality (not important). After I publish and try to install it, I get the following error:
Unable to install this application because an application with the
same identity is already installed. To install this application,
either modify the manifest version for this application or uninstall
the preexisting application.
I've tried changing the assemblyIdentity version number and name in the Properties -> app.Manifest, tried changing the Assembly name in the Project properties, tried clearing the manifest cache and none of these worked. I realize that this is the same application that I'm trying to install on two different websites on the same server, but what needs to be changed so that it will install correctly?
You need to change the Product Name of your application's deployment. This is the application name stored in the deployment manifest file. Making this name different between your 2 instances will allow you to install both of them at once. If setting this through Visual Studio, this is under the Options button on the Publish tab of your project's properties window.
The NuGet web site has an excellent article for hosting your own NuGet feed. In our case we are an IT shop that needs to fully vet packages before making them available to our development staff so we would like to host our own feed which will provide "approved packages". One thing the article glosses over is how to pull down the nuget packages for hosting. So for example if we want to host EntityFramework 5.0.0 so our developers can use it how do we get the package without using NuGet as policy prevents NuGet accessing hosts past our firewall?
Assuming you're not completely cut off from nuget.org, you could use ProGet to host your network's feed. Since ProGet allows you to both create multiple feeds and also to connect to other NuGet feeds, you could create one feed, say "NuGet Cached", and then a "Developer" feed, and specify the same package storage location for both feeds. The trick would be to set up a connector to nuget.org on the "NuGet Cached" feed, then use the Pull Package feature to download the hosted NuGet packages to your local feed.
This way, developers would set up Visual Studio (or whatever tool they use to get the packages) to point to the "Developer" feed which only has the packages you have explicitly pulled down (since both feeds store packages in the same location). You could also add deny privileges to the "NuGet Cached" feed such that they can't connect to it at all.
Create a host server (sounds like you have, but if not it's installing and hosting a NuGet.Service).
Confirm it's working by visiting the host (should see a very simple dashboard saying the Nuget service number, etc)
open VisualStudio options, "Pakcage Manager"->"Package Sources"
Add your internal host here (probably something like http://internalsvr/nuget)
Then you should be able to install packages form that source locally. also, you can push things up there, or place the packages in the ~/packages/ directory and they will automatically be listed in the service.
You can probably try out http://www.myget.org or use any of the other software out there.
I have just completed (basically) a beginner's database application with SQL Server and Visual C#. I am using Visual C# Express, not the full-scale Visual Studio thing, which apparently makes deploying the application properly a bit more complicated. I've seen where some other people have asked about how to deploy such an application from that IDE, but I'm not able to fully understand and use some of the answers that they've been getting back.
Therefore I must ask how to deploy this application properly, but I must also ask that there be a simple walkthrough given. College doesn't teach much about how to deploy these things, so I'm very newbish at it. Thanks!
I don't know of an automated way to deploy the database. If it's the first time the database is hitting the server, I backup on the source, and restore on the target...simple.
As far as the code, here's what I do:
Publish (right-click, Publish) the code to a local directory (I use C:\Websites\SiteName).
Use and ftp client to promote the output to the server.
Make any necessary adjustments to the web.config to point correctly to your target database.
When and if you need to make changes later, you might want to consider a tool I use for this purpose, BeyondCompare. It can perform a diff between your local files and the target site via FTP, and tell you exactly what you need to deploy to make it work. This won't detect changes in your db, however, though there are plenty of Sql diff tools along the same lines. My general principle is "make the local site work perfectly, and then make the target site just like the local site".
Things to watch for in #3 above are that the target address is right in the connection string, along with whatever security credentials you will need to connect to the db.
HTH.