By Brian Dukes on
1/29/2008 2:44 PM
As a developer, and specifically as a DotNetNuke developer, there are a number of directories that I have to navigate to regularly. In particular with DotNetNuke, I'm going to C:\inetpub\wwwroot\DotNetNuke\Website\DesktopModules quite a bit. So, instead of having to try to type that in all the time, or navigate through the folder structure, I've defined an environment variable "dm" that is defined as that path to my Desktop Modules folder. I can just type %dm% into an explorer prompt and be there without any hassle. I've also setup a %wwwroot% shortcut, though it gets used much less often. It's a lot like keeping a shortcut around in your dock/quick launch toolbar, but you can also use it in dialogs. Hopefully this can help you trim off a few more seconds/minutes of monotony throughout your day.
...
Read More »
|
By Chris Hammond on
1/25/2008 12:12 AM
For those of you who may have missed it, Engage: Publish 4.5 released last week. This release has some big improvements for the module, and lays the groundwork for a new major releasing coming in the next month or so. Read more for more information!
Read More »
|
By hkenuam on
1/18/2008 9:38 AM
Recently one of my colleagues (Dukes) and I were developing a module and he is one of those guys who has memorized every keyboard shortcut for Visual Studio and I noticed him "Attaching to a Process" (CTRL + ALT + P). Me being a traditional style developer I have always just reloaded the application using the trusty F5. We were involved in some client specific business logic and I just made a mental note at the time.
Recently, I've started using the Attach to Process (then select aspnet_wp.exe and Attach) as the way to test logic and I have to say that it is much faster than F5 even with cached authentication information and not logging in each time.
If you are like me and you are a habitual F5er, give attach to process a try, old habits are hard to break but this one will save you a significant amount of time over the course of a day, week or your career!
|
By Brian Dukes on
1/9/2008 4:44 PM
We have released a major update for Engage: Employment, our DNN job listing module. In version 1.2, we have added a number of new features and fixed all known bugs from version 1.1.
The most exciting new feature for Employment is the addition of Job Groups, which will allow much more customization and flexibility when using the module. You can now assign jobs into job groups, and then set up various modules to display and edit specific job groups. Before now, there was no way to segregate your jobs, every module always showed every job. Now, you can separate jobs between locations or categories, or any way that you want. In addition, you can also assign different security permissions to each module to better control who gets to create and update various job listings on your site.
Once you upgrade, you can add the Engage: Employment Job Group Admin module onto a page, and create the groups that you need...
Read More »
|
By Brian Dukes on
12/14/2007 2:56 PM
It's occasionally tricky/troublesome to pass the current Portald from your DotNetNuke control that inherits PortalModuleBase so that it can be used in your business object logic. A trick that I learned looking at another developer's code recently is to get the current PortalId from PortalController.GetCurrentPortalSettings().PortalId. CurrentPortalSettings is set for every request, so it is always the value that you are looking for.
Hope it helps,
|
By Brian Dukes on
12/14/2007 2:49 PM
I tend to run one of the latest versions of DotNetNuke for my development website, however I still want to compile against an older version so that my assemblies are compatible with the older versions. So, I create a folder outside of my website (C:\Assemblies) with a directory for each version of DNN (and the Ajax Control Toolkit) that I might want to target. I fill each directory with the contents of the bin folder from the DNN install (or Ajax Control Toolkit website), and then set a resource path in my project that points to that specific directory. Voila, running 4.7.0, compiling against 4.5.1.
You'll need to make sure that your project doesn't set the Copy Local property on each reference, since that'll copy the old assembly over the new assembly and break your website.
Hope it helps,
|
By John Eimer on
12/13/2007
We have finally made the first public release of Engage: Locator on Engage Modules. If you want to make it easy for the visitors to your website find your business locations, Engage: Locator is the solution. We've invested a lot of time in making it user friendly and configurable and has finally reached a point where we could release it. Have a look on our demo site and see if this could add a nice touch to your site.
|
By Chris Hammond on
12/12/2007 12:19 AM
In April of this year I threw a little module together called Engage: F3 that allows site administrators and superusers to easily search for strings of content within their Text/HTML modules and Engage: Publish content on a site. Recently I've taken the time to come up with a new release of the module that provides Search and Replace functionality for the Text/HTML module.
Read More »
|
By Chris Hammond on
12/10/2007 12:39 AM
Tonight we released the latest version of Engage Publish, 4.4.4 (12/9/2007). This release has a few minor bug fixes, a few UI improvements, and some enhanced features!
Read More »
|
By Ian Robinson on
12/9/2007
If you have recently edited your reporting services web.config and can no longer access your reports you may want to check if your web.config file contains an xmlns attribute on the configuration element. If it does, you will not be able to access your report manager. Simply removing the attribute will solve this issue.
I ran into this issue today after i edited a property in the web.config using the IIS tool (under asp.net tab). As i had no idea what had originally caused the issue it took a few hours to figure out that it was because i had edited the web.config with IIS.
Here is the error message that the report manager would display:
"The report server is not responding. Verify that the report server is running and can be accessed from this computer."
Here is the error message from the log file:
Microsoft.ReportingServices.Diagnostics.Utilities.InternalCatalogExcepti
on: An internal error occurred on the report server. See the error log
for more details. ---> System.NullReferenceException:...
Read More »
|