cAppPool resource not executing about dsc HOT 8 CLOSED

Thanks.. I'll take a look

from dsc.

So what I did to fix this was simply delete the .psd1 file. I guess because I'm importing it via the cWebAdministration Module, and not just the cAppPool module, that file was causing issues...

from dsc.

I think I know what was happening in this case.. git tends to mangle .psd1 files (by trying to be helpful and adjust line endings. I'm going to blog about this shortly and will be pushing a change to the repo to tell git to knock that crap off.

from dsc.

I'm running into the same issue as well. I've tried the previous solution of deleting the psd1 file which does allow the MOF files to be built that consume the resource. The issue I'm getting is when running Start-DSCConfiguration I'm getting the following error "Could not get the module with the following name: PSHOrg_cAppPool. Check if the module exists under PSModulePath".

I've also tried to 'repair' PSHOrg_cAppPool.psd1 as it was missing quotes and the GUID but only ran into more errors.

Am I missing something?

from dsc.

Just to confirm this is still happening with the cAppPool resource. Steven's quick fix of deleting the PSD1 seems to work.

Interestingly I looked at some of the experimental DSC resources from Microsoft and they don't include a PSD1 for each resource. There is a PSD1 for the parent module but each resource is purely a PSM1 and MOF schema file. There's a bit of inconsistency about whether they use an "Export-Moduolemember" to export the functions within the psm1.

I'd be inclined to suggest that the community DSC resources follow a similar pattern of only using the PSD1 at the base module and not include one for each DSC resource?

from dsc.

Fixed on https://github.com/PowerShellOrg/cWebAdministration . The module manifest was missing its RootModule key, causing the PSM1 file not to load properly. (Deleting the optional psd1 file was also an option, but I decided to leave it since it contained author credits and such.)

from dsc.

And I'm in favor of keeping the PSD1. There are still a few edge cases I've hit where resources would not load without one.

from dsc.

That's interesting... I actually removed the psd1 from my fork, but will add it back.

from dsc.