Saturday, November 17, 2007

Inconsistent accessibility: base class is less accessible than class

I was doing some coding in c#. I had one class but decided to split it up so I could reuse some of the functionality later. So I made a simple shell and started moving pieces into the parent class.

On my first compile I got this message: Inconsistent accessibility: base class is less accessible than class

I am a little rusty with my C# and classes, but it turns out I left off the public keyword on the new class. Adding public fixed that compile error.

Tuesday, November 13, 2007

Mapped drives missing in explorer.

We ran into a problem with our mapped drives on our network. First time logins failed to display in explorer until they logged in the second time. You can see them from a command or dos prompt. The disconnect drives dialog also showed the mappings. I can also kill the explorer.exe process and when I run it from the task manager, the mapping show up.

Running the logon scripts manually will make the drives show up. It looks like a timing issue. If my script maps a lot of drives, the earlier ones are the ones that don’t show up. Any that map after explorer loads work fine. It did not matter if it was the users individual logon script or the group policy log on script. Different logon scripts didn’t fix it either. I have a custom vb script that I use, but I also tested it with a batch file full of NET USE commands.

I have worked on this issue for a long time. Searching different ways and posting to various forums. Finally Lanwench [MVP - Exchange] responded to my problem on microsoft’s technet newsgroup on Windows XP Networking. His solution was to enable the “Always Wait for Network” GPO setting and linked me to the detailed reason for that.

Always wait for the network at computer startup and logon

Administrative Template: System
Policy Node: MACHINE
Policy Path: Administrative Templates\System\Logon
Supported On: At least Microsoft Windows XP Professional or Windows Server 2003 family

Help/Explain Text: Determines whether Windows XP waits for the network during computer startup and user logon. By default, Windows XP does not wait for the network to be fully initialized at startup and logon. Existing users are logged on using cached credentials, which results in shorter logon times. Group Policy is applied in the background once the network becomes available. Note that because this is a background refresh, extensions such as Software Installation and Folder Redirection take two logons to apply changes. To be able to operate safely, these extensions require that no users be logged on. Therefore, they must be processed in the foreground before users are actively using the computer. In addition, changes that are made to the user object, such as adding a roaming profile path, home directory, or user object logon script, may take up to two logons to be detected. If a user with a roaming profile, home directory, or user object logon script logs on to a computer, Windows XP always waits for the network to be initialized before logging the user on. If a user has never logged on to this computer before, Windows XP always waits for the network to be initialized. If you enable this setting, logons are performed in the same way as for Windows 2000 clients, in that Windows XP waits for the network to be fully initialized before users are logged on. Group Policy is applied in the foreground, synchronously. If you disable or do not configure this setting, Windows does not wait for the network to be fully initialized and users are logged on with cached credentials. Group Policy is applied asynchronously in the background. Note: If you want to guarantee the application of Folder Redirection, Software Installation, or roaming user profile settings in just one logon, enable this setting to ensure that Windows waits for the network to be available before applying policy. Note: For servers, the startup and logon processing always behaves as if this policy setting is enabled.

Registry Settings: HKLM\Software\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon!SyncForegroundPolicy

Friday, November 02, 2007

Christmas Wish List

People keep asking for a wish list for Christmas. I'm a hard person to buy for sometimes. I usually don't need very much. When I do see something I want, I have a hard time not buying it early.

I recently purchased a Nintendo Wii. That does open a lot of options for gifts. I made a wish list on amazon that contains the Wii stuff I want.

My Wish List

Each game adds different value to the Wii.

Super Mario Galaxy: Every Nintendo has a Mario platform game that pules you into the system. Its a showcase of design and interaction with the system. This game it exactly that. Mario is new every time its released and becomes a must have game.

Mario Party 8: With the focus of the Wii around group interaction and fun, this game builds on that even more. With a lot of mini games and the option to play 4 people at once, your group will have lots of fun on this one.

Metroid Prime 3 Corruption: Another household Nintendo name that never lets you down. This is a highly interactive first person single player adventure.

Super Smash Bros. Brawl: to be released just after Christmas, its a arcade fighting style game. It pulls in all the classic characters from several popular titles and puts them in the ring against each other.

Super Monkey Ball Banana Blitz : A Sega release that places you in control of a glass ball. You tilt and turn the ground under the ball to control its movements. sounds like its easy to pick up and learn. The difficulty gets insane by the time you finish.

Friday, October 19, 2007

Stop or Disable Terminal Server Logons (Change Logon)

Here is a simple command that I had a hard time finding.

Change Logon /Disable
Change Logon /Enable

It prevents users from logging on to the server that the command was ran on. All new connections will be disabled. Existing connections will not be disconnected. So you can run this with remote users logged in to stop new connections while you wait for people to exit.

You can run that from a terminal session. If you get disconnected, you will have to get physical access to the machine to activate it.

From the website: Enables or disables logons from client sessions, or displays current logon status. This utility is useful for system maintenance.

http://technet2.microsoft.com/WindowsServer/en/Library/15a2f502-1fa3-4d3b-a74b-cec04ee52d061033.mspx?pf=true

Running VB.NET code in VBScript or other apps

Here is how you can write a .NET component and use it in a script. First, create a library that contains the code you want to run.

Public Class FileWriter
Public Sub Save(ByVal PathAndFileName As String)
Try
Dim FileStream As New System.IO.StreamWriter(PathAndFileName, False)
FileStream.WriteLine("Hello World")
FileStream.Flush()
FileStream.Close()
FileStream.Dispose()

Catch e As Exception
Dim fs As New System.IO.StreamWriter("C:\error.txt", True)
fs.WriteLine("Exception: {1}", 1, e.Message)
fs.Flush()
fs.Close()
fs.Dispose()
Throw e
End Try

End Sub
End Class


Then compile the library and run regasm c:\project\bin\NameOfDLL.dll /CODEBASE to register it. Regasm is in your .net folder. That will register the dll so you can use it later. Regsvr32 is for non .NET dlls. Your script is next. Save it as a .vbs file.

dim fs
set fs = CreateObject("Project1.FileWriter")
fs.save "c:\file.txt"
set fs = nothing

Anyplace you can call CreateObject, you should be able to use your class. VBA in office is one such place. And I did not test this code, I just gutted another project to have some examples.

Related: Running vbs from .net code

mscorlib: Request for the permission of type Version Culture PublicKeyToken failed.

I wrote a little database access code in vb.net that I wanted to use in another script. I was getting this error though. C:\Test.vbs(6, 1) mscorlib: Request for the permission of type 'System.Data.OleDb.OleDbPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

My dev machine worked fine. And the other box looked like it had the data access and .NET components I needed. Looking closer, it was talking about permissions. The connection string was the same and it contained the password. I decided it was a security zone messing me up.

When I ran regasm, the dll was located on a network share. That was about the only difference. So I unregistered it, moved it locally, and ran regasm again. The problem went away.

mscorlib: Request for the permission of type Version Culture PublicKeyToken failed.

Thursday, October 18, 2007

The system cannot find the file specified. CreateObject

I was attempting to use some vb.net code in a vbs file and was getting "The system cannot find the file specified." on the CreateObject line. I tracked it down to the way I registered the DLL.

One sugestion told me to unregister and re register it with regsvr32. Because I was using .NET, I knew that was not it. It turned out to be my use of regasm to register my DLL. I left out the /CODEBASE option.

Once I registered it with that option, the error went away.