none
VSeWSS 1.3 Feedback and Feature Requests

    Question

  • First of all I would like to say this tool has improved quite a bit since the last version.  However, I still feel that it has a long way to go before a SharePoint developer would actually consider using it.  The functionality I am targeting today is the web part functionality.

    I really like the added options to Deploy, Package, and Retract Solutions added to the context menu of your solution.  These all seemed to work really well.  I was able to create a quick Hello World web part and deploy it.  I activated it manually and was able to view it immediately.  One thing, I am very appreciative of is the ability to choose between a Full Trust or Partial Trust web part when you create the project.  You still have to specify the Code Access Security settings yourself, but at least it is possible now.  I am also a fan of the new options to quick deploy directly to the bin folder and 12 hive.

    As a SharePoint developer, I put a lot of files into solution packages.  Pages, XML files, Master Pages, Site Template Definitions, you name it.   I want to be able to put these files in my wsp.  I assumed WSP View would have this functionality.  You can get to it by going to View -> Other Windows -> WSP View.  Maybe, there is functionality there, but I couldn't figure out how to add any files to the package.  You have no direct access to the DDF file and there are no menu options to allow you to customize or add files in WSP view.  There is an option to add another feature, but you can't customize what files to add along with the feature.  Somehow, when you create a new web part project, the .webpart file shows up in the WSP view, but I have no idea how.  This by itself, means I can't use this tool.  Again, if I am just being stupid and can't find it, let me know.  The one thing I will note here is that you can customize the manfiest file here. 

    Another thing, I found lacking is that I can only add one web part per project.  Sure, I can manually create another class, but I want it to generate the .webpart file for me and put it in the solution.

    Features I would like to see:

    • Remote SharePoint Server support - Let me install it on a Windows XP machine (without WSS obviously) and specify the URL to my SharePoint server.
    • Ability to customize contents of WSP file
    • Better CAS support - A tool to help determine security policies would be great
    • Multiple web parts in one project
    • Better control of what goes into the solution package

    I know the product is just a CTP, so hopefully, with some good feedback we can get a tool we can all use.  I guess for now its back to manual creation, stsdev, or WSPBuilder.  Microsoft has relied on the community too long for SharePoint tools, it is time they produce.  Am I off base here?  Anyone have other feature requests?  What tools do you use?

    Crossposted on DotNetMafia.com

    Thanks,
    Corey Roth

    • Changed type Mike Walsh FIN Monday, February 23, 2009 9:47 AM Always use the Question type so people who reply get credit
    Thursday, February 05, 2009 9:21 PM

All replies

  • Hi Corey,

    Thanks for the feedback. I wanted to answer some of your questions.

    For the partial trust web parts, we have added the code access security work. It's not a tool, but we provide out of the box minimal defaults that let you build and deploy the web part to the BIN folder.

    For the extra file deployment that you talk about we have added a few things that allow you to to add miscealaneous files in different places such as RootFiles, additoinal DLL deployment, etc. We're working hard to make sure some of these specific extensibility actions are documented in the release notes. You can customize the manifest, add custom features as folders in the solution explorer or add custom features with the new button in the WSP View.

    You can have multiple web parts per project. We only do one web part per feature though, perhaps that's what you meant.

    Sorry we weren't able to support remote development. There are a few options of course but all of them need Visual Studio 2008 and Windows SharePoint Services 3.0 on the same machine.

    You can customize the contents of the WSP. Perhaps the methods are difficult to figure out for yourself. We'll try to get this well documented.

    I hope this helps. I know there are a lot of people using these extensions and we're really trying to improve them in this revision.

    Regards,
    Paul
    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Thursday, February 05, 2009 9:59 PM
  • Thanks Paul for the quick reply.  You all are making great improvements and I am glad to se MS actively working on this.  
    As for the multiple web parts per project, I couldn't figure out how to add a second web part and have it automatically add the files to the solution package.  I should have been more clear.

    Remote development is a big thing for me.  Even if you can't get it implemented, could you at least let me install the tools on machines without WSS on them?  Just like a workflow project, I can copy that project file to another machine after it has been created on a WSS machine.  I know I can't get full functionality, but it would help a ton.  It would be nice to at least be able to compile and build a solution package and then manually deploy the package.

    So how do you customize the wsp then?  I figured there would be a context menu in WSP view or something.  

    Thanks again for the response.

    Corey
    Thursday, February 05, 2009 10:06 PM
  • Hi Corey,

    We can't support the tools on a Windows client OS, but if you could upgrade to Windows Vista or Windows 7 there are two options which I've heard of people doing. One is the set the registry value that VSeWSS requires before it will install. You can find the right one with ProcMon from Windows Sysinternals. The other is the third party published process for installing WSS 3.0 on Windows Vista. Neither of these options is supported by Microsoft.

    Regards,
    Paul
    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Friday, February 06, 2009 8:00 PM
  • Hi

    I would like to add my six pennys worth in here.....

    One of the biggest issues I have is that SharePoint Designer has its own check in / check out and Visual Studio has its own check in check out (via TFS or VSS).  Why cannot the two be harmonised as I like to deploy my Master Pages and Page layouts as solutions so I have to check them out of SPD copy and paste them into Visual Studio.

    I have not seen anywhere yet that this will happen either this CTP or slated for the next version of VS.  Perhaps I missed it ?

    Thanks

    Nigel
    Tuesday, February 10, 2009 11:30 PM
  • Hi Nigel,

    SharePoint Designer is a different product to Visual Studio. So the source code control of SharePoint Designer artifacts isn't something we can solve in VSeWSS which is an add in for Visual Studio.

    There's one solution here: http://blogs.msdn.com/mwasham/archive/2008/11/20/how-to-extract-aspx-files-out-of-a-sharepoint-content-database.aspx

    Regards,
    Paul 
    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Monday, February 23, 2009 2:21 AM
  • Hi,
    one of the nice things about WSP view is that you can easily change the order of your features, so that they are deployed and activated in dependency order. The problem here is that the same order is applied on deactivate; it would make more sense to apply the reverse order. Currently I need to deactivate my features in dependency order then use the retract command within Visual Studio, otherwise I get into all kinds of problems.

    Regards,
    Mike
    Thursday, April 16, 2009 2:05 PM
  • Corey,

    I just want to point out (at least some of) WHY remote deployment doesn't work.

    Exploring the process of deployment: build/compile, generate WSP, use STSADM to install, IISRESET.
    Unfortunately, STSADM does not allow *any* way to access remote servers (more specifically, there appears to be no way within the API/OM to connect to a remote server)... thus, the only way this would possibly work, is if you configured a location to store the WSP on the remote server, credentials to access the remote server, and then remotely execute STSADM and IISRESET... and then figure out how to get error messages back.

    Then, let's consider debugging... to debug code requires exclusively locking the IIS worker process (w3wp). This would mean that *nobody* can use the server EXCEPT the developer. If that's the case, why is the developer using 2 boxes?

    I know it sounds great in concept, but SP Dev really only makes sense to perform on WSS.

    I've also found that virtual PC's are worth using for other reasons: if you're developing a feature (say a web part)... you don't want previous work (say other web parts, site templates, etc) to interfere with whatever you're currently working on. Debugging includes this as well - you don't want to be pulling your hair out because of a bug in a previous project/solution.

    I've created a "base" SP Dev image, and I just copy and reuse it for each project... perhaps not the most effecient, but it isolates the heck out of the work.

    My only *real* complaint is that VPC is single threaded and seems to be ignored in favor of Hyper-V... but that's for another thread altogether :)

    -Scott
    Thursday, April 16, 2009 3:37 PM
  • I agree entirely... I would like to see better support for dependencies... both feature dependencies, and project references (if one project is a class library, used by another project).

    Thanks,
    -Scott
    Thursday, April 16, 2009 3:38 PM
  • Paul-

    Is there a way to stop the creation of assemblies, as mentioned in this post 3 years ago?

    http://scothillier.spaces.live.com/blog/cns!8F5DEA8AEA9E6FBB!671.entry

    I don't need or want any assemblies, but I can't find a way to eliminate them even using the latest VSeWSS.  Is there some way to do this?  The "empty" project tempate isn't quite as empty as I'd like.

    Thanks, Clark
    Thursday, April 16, 2009 3:41 PM
  • Scott,

    Honestly, I would be perfectly happy if it could just spit out a wsp file on my Windows XP machine.  That would be a big win.  I have no issue with copying the wsp file to the server manually and remote debugging.  But honestly, a lot of the functionality is implemented in VSeWSS 1.3 could work remotely, because they created a web service to provide a lot the administrative functionality that is there.  They have it locked down to the local server for security purposes, but this could be configured otherwise.  We're still developing on a virtual environment, we just have multiple virtual machines that are hosted on a server instead of locally on a desktop. 

    The fact is I develop remotely all the time and I have a custom build action which creates my solution package on a non-sharepoint machine that works just fine.  It would just be nice if I could use some of the builtin templates of VSeWSS 1.3 instead of manually creating everything (or using another tool).

    Thanks,
    Corey
    Corey Roth blog: www.dotnetmafia.com twitter: twitter.com/coreyroth
    • Proposed as answer by skyW Monday, June 01, 2009 10:17 AM
    Thursday, April 16, 2009 3:43 PM
  • Paul-

    Is there a way to stop the creation of assemblies, as mentioned in this post 3 years ago?

    http://scothillier.spaces.live.com/blog/cns!8F5DEA8AEA9E6FBB!671.entry

    I don't need or want any assemblies, but I can't find a way to eliminate them even using the latest VSeWSS.  Is there some way to do this?  The "empty" project tempate isn't quite as empty as I'd like.

    Thanks, Clark

    Hi Clark,

    I don't know of any way to do this with VSeWSS 1.3. I've added your request to our list. Thanks for the suggestion.

    Regards,
    Paul
    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Tuesday, May 05, 2009 4:35 PM
  • Hello Paul,

    First thank you for monitoring this forum from the Microsoft side... It is great to realize the fact that our feedback is actually appreciated...
    I have quite an experience working with WSS and MOSS and our team has already implemented several SharePoint solutions for a big company. To achieve the maximum flexibility we as probably everyone else developing for production systems work with scripts, generating files, packaging and deploying in a "manual" fasion. Different third party tools help, but not much, therefore I pay close attention to the development of VSeWSS and really hope that it can turn into a primary tool for SharePoint developers.
    As Corey correctly mentioned VSeWSS 1.3 is a big step forward. What I personally would like to see there adding or precising the comments of other people here is:
    1. Ability to control the generation of a setup.bat file... It is created by the "black box" nobody knows how to access...
    Example:
    I created a feature and added it to the solution as a library. Then I added a reference to it, modified manifest file and changed its scope to WebApplication, added CAS policy to the solution manifest. When setup is produced there is no -allowcaspolicies flag... I can manually add it, but when I clean the solution it's gone again...
    If I add a feature, it automatically adds its activation command in the setup.bat - what if I want to activate feature in my site definition?
    Having some control options here would be appreciated.
    2. Project referencies. Is there a chance to add Sharepoint projects (Wep part project, List definition etc) to the solution so when they are referenced, they are not packaged as WSPs (by setting let's say a particular project property), but its files and assemblies are included in the WSP solution manifest being packaged? Or when I add a web part item to the site definition project, can I specify that its assembly is in a different project? The natural or an "established" way of working with WSPs is to collect files and assemblies from different projects gathering them under one WSP roof.
    3. When I create a site definition project and try to deploy it - it needs a site collection already created and complains that site url is not found. I was hoping that deploy command would create a site collection based on my site definition...

    Thank you very much for all the work and efforts you put in the development of these tools...

    Regards,
    Alexei
    Tuesday, May 19, 2009 9:33 PM
  • Hi Alexei,

    Great to hear from you. In response to your three suggestoins:

    1) Control generation of setup.bat

    In the original version setup.bat was intended to be used for deployment during debug cycles. We stopped using it in favour of calling SharePoint API's directly for deployment but kept it in there as an aid for developers. It isn't intended for use in production but it could be used as a starter for your production deployment script. Specifically it doesn't have options for farm deployments that are often recommended. You could write some perl code to take the output of setup.bat and modify it each time it comes out of VSeWSS if you really want to use that.

    2) Project references

    Not sure it helps you exactly, but in VSeWSS 1.3 we added the ability to add additional DLLs into the WSP being packages. These can be from other projects. To do this check the Copy Local property for the referenced DLL. There's a little more info about this in the VSeWSS 1.3 Release Notes.

    3) Site definitions

    Yes, good idea. No we don't do that in VSeWSS. I can add this to the request list also.


    Regards,
    Paul
    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Wednesday, May 20, 2009 3:01 AM
  • Hi Paul,

    Thank you very much for the reply; it cleared a couple of points. Especially the fact that setup.bat is not used anymore during the deployment (chm to be updated ! :)) The only remark I have on the first point is that VSEeWSS tries to automatically activate features when deploying. It would be nice to be able to choose which ones to activate...

    As for the project references... What I wanted to say was that right now adding an Empty project or a Web Part project to the solution already containing Site definition project doesn't make a lot of sense... Every single project would produce WSP (that takes time) and you still need to reference their assemblies and add manifests as features to the "main" site definition project. If I use a class library project instead, reference it and add features in my site definition project then CAS policies for example are not generated (because it doesn't know which assembly this feature is linked to) and I have to add them manually. Some explicit binding would help I suppose.

    Another suggestion: would it be possible to choose what to do on F5 (Deploy or Quick Deploy)? If I have a site definfition project then I normally deploy it once and mainly test features, controls and web parts functionality. So I would prefer to "quick" deploy and start web app with the debugger attached... What do you think?

    Thank you again for the great support,

    Kind regards,
    Alexei

    Wednesday, May 20, 2009 8:17 AM
  • Hello,

    I installed v1.3 to the same drive where my Visual Studio 9.0 is installed, which is NOT the system drive.   I've created an empty project but cannot create a new feature in WSP view.  The following error appears in the VSeWSS1.3log:

    Error: System.IO.DirectoryNotFoundException
    System.IO.DirectoryNotFoundException: Could not find a part of the path 'F:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplatesCache\CSharp\SharePoint\1033\FeatureReceiver.zip\FeatureReceiver.vstemplate'.
       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
       at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials)
       at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn)
       at System.Xml.XmlTextReaderImpl.OpenUrlDelegate(Object xmlResolver)
       at System.Threading.CompressedStack.runTryCode(Object userData)
       at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
       at System.Threading.CompressedStack.Run(CompressedStack compressedStack, ContextCallback callback, Object state)
       at System.Xml.XmlTextReaderImpl.OpenUrl()
       at System.Xml.XmlTextReaderImpl.Read()
       at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
       at System.Xml.XmlDocument.Load(XmlReader reader)
       at System.Xml.XmlDocument.Load(String filename)
       at Microsoft.SharePoint.Tools.Wizards.NewFeatureWizard.SetWizardData(String templateFilePath, Dictionary`2 replacementsDictionary)
       at Microsoft.SharePoint.Tools.Wizards.NewFeatureWizard.RunStarted(Object automationObject, Dictionary`2 replacementsDictionary, WizardRunKind runKind, Object[] customParams)
       at Microsoft.SharePoint.Tools.Forms.SPToolWindowControl.CreateFeature()
       at Microsoft.SharePoint.Tools.Forms.SPToolWindow.CreateFeature(Object sender, EventArgs arguments)

    It is looking for a folder (Microsoft Visual Studio 9.0) on the system drive that does not exist.  What do you recommend I do?

    Thanks...
    Wednesday, June 03, 2009 5:52 PM
  • Hi Vic,

    This is a known problem. VSeWSS 1.3 requires Visual Studio 2008 to be installed on the C drive.

    Please start new questions on new threads.

    Regards,
    Paul
    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Wednesday, June 03, 2009 6:06 PM
  • Paul,

    I'm confused. Above you state that

    Not sure it helps you exactly, but in VSeWSS 1.3 we added the ability to add additional DLLs into the WSP being packages. These can be from other projects. To do this check the Copy Local property for the referenced DLL. There's a little more info about this in the VSeWSS 1.3 Release Notes.


    But the release notes state...

    This commonly happens if your SharePoint project references another project. Referenced projects are not supported. Instead of referencing another project, reference the compiled DLL from the project directly and it will get included.


    The above two statements seem contradictory to me. When I go Add Reference for the 2nd Project what should I specifically do please?

    If I have a SOLUTION with 2 projects in it. Both projects created from the Sharepoint Empty Project template. If my 2nd project needs to reference a DLL from my first project (e.g a Utility.dll of my own)...please provide specific steps as to what I should do.


    Thanks,

    Saturday, June 13, 2009 1:11 PM
  • But the release notes state...

    This commonly happens if your SharePoint project references another project. Referenced projects are not supported. Instead of referencing another project, reference the compiled DLL from the project directly and it will get included.

    Is this text from the 1.2 release? I can't find it with search in the current version. The 1.3 release notes can be downloaded here.  

    http://www.microsoft.com/downloads/details.aspx?FamilyID=B2C0B628-5CAB-48C1-8CAE-C34C1CCBDC0A&displaylang=en

    We optimized the inclusion of separate DLL's in WSPs for refreenced DLL's rather than referenced projects. You need to set CopyLocal = true to activate it and you may have some success with referenced projects.

    Regards,
    Paul


    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Saturday, June 13, 2009 3:22 PM
  • Hello Paul,

    I have two questions/suggestions:
    - Is there any chance to add context menus in WSP View?
    - Can you add "Feature options" option to control which site definition configuration this feature should registered in and whether it should be registered at all.

    Known issues:
    - I believe you know about the "Unable to load one or more of the requested type" issue when you try to inherit from a type defined in a assembly referenced from VSeWSS project. I was curious if you plan to solve it in a final release, since it affects the way solution needs to be build.

    Thank you,
    Regards,
    Alexei
    Friday, June 19, 2009 8:07 AM
  • Hello All,

    I have noticed some small bugs:
    - If you move VSeWSS project under a Solution Folder, the VSeWSS deployment options (Package, Deploy, Quick Deploy etc.) are not displayed anymore.
    - If VSeWSS project is more than one level deep relative to the solution folder, WSP solution cannot be generated ("Value does not fall within the expected range" exception)

    Regards,
    Alexei
    Friday, June 19, 2009 2:27 PM
  • +1 for being able to control which features get activated on deployment...
    Saturday, June 27, 2009 11:35 AM
  • Hello All,

    Will there be a switch to turn on /off solution validation when packaging? This phase takes most of the time, sometimes up to 10 minutes (depending on how many files are there in the solution). Is there any way to control that?
    Wednesday, August 12, 2009 9:05 AM
  • Hi Alexei,

    No unfortunately we aren't able to add that.

    Regards,
    Paul
    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Sunday, August 16, 2009 3:53 AM
  • Hi Paul,
      Are there any release dates for VS3ESS 1.3? I heard somewhere it will be out by July but that has come and gone. I really would appreciate if you could provide some ballpark figure.

    Thanks.
    Monday, August 17, 2009 8:27 PM
  • Another vote to be able to select which features to activate on deployment!
    Friday, August 21, 2009 5:46 PM
  • Hi Paul,
      Are there any release dates for VS3ESS 1.3? I heard somewhere it will be out by July but that has come and gone. I really would appreciate if you could provide some ballpark figure.

    Thanks.

    Hi Kris and Everyone,

    We have had some delays in the release processes for VSeWSS 1.3. The new estimated release to web (RTW) date is the end of October 2009. We will work hard to keep to this deadline.

    I notice you wrote this question 2 weeks ago. You can always contact me more directly through contact on my blog http://blogs.msdn.com/pandrew

    Regards,
    Paul
    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Monday, August 31, 2009 4:27 PM
  • Hello guys and Paul,

    What are my options if I need to produce a package that should contain only 3d party components and nothing else? Will there be a chance not to include the VSeWSS project output assembly in the manifest.xml automatically?

    Thank you,
    Alex
    Thursday, September 03, 2009 7:07 AM
  • Here's a post detailing another possible cause/solution to the "Value does not fall within the expected range." error. Hope it helps someone.

    http://foxsys.blogspot.com/2009/09/value-does-not-fall-within-expected.html
    Friday, September 04, 2009 8:04 PM
  • Hello guys and Paul,

    What are my options if I need to produce a package that should contain only 3d party components and nothing else? Will there be a chance not to include the VSeWSS project output assembly in the manifest.xml automatically?

    Thank you,
    Alex

    Hi Alexei,

    VSeWSS is not able to package without the project DLL.

    Regards,
    Paul
    SharePoint Product Manager. Posting is provided "AS IS" with no warranties, and confers no rights
    Friday, September 04, 2009 8:34 PM
  • I would like to add to the request to not be forced to include the project assembly in the manifest.xml.  I really hope this can be added to the next release.
    Tuesday, September 15, 2009 7:42 PM
  • +1 for the request to not be forced to include the project assembly in the manifest.
    Wednesday, November 18, 2009 4:45 PM
  • Hi

    I think VseWss has long way to go it is not ready to be used because it should first follow the architecture of SharePoint to be good deployment too for example :

    you can create list definition using the template provided for that list definition you can create list instance in SharePoint when you create list this later reference its list template using feature ID the problem is that vsewss change the feature ID all the time what happens is that when you uninstall solution and deploy the wsp if you had list this later will complain that it could not found the list template feature actually this list is referring  to the old feature ID the same feature had been deployed with new feature ID.

    Another drawback that I think is in the fixing phase is the impossibility of using feature properties such as ActivateOnDefault, scope, etc. Because the feature files is overwritten dynamically every time you deploy.

    Hope this helps


    Momo
    Thursday, August 26, 2010 4:08 PM